Doc: explain about dependency tracking for new-style SQL functions.

5.14 Dependency Tracking was not updated when we added new-style
SQL functions.  Improve that.

Noted by Sami Imseih.  Back-patch to v14 where
new-style SQL functions came in.

Discussion: https://postgr.es/m/2C1933AB-C2F8-499B-9D18-4AC1882256A0@amazon.com

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 458b89c0cba9e3002de376ad252be50e4c932a57..e32f8253d03b4c99a0236a39302a038ae9c9d8a4 100644 (file)
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -5235,8 +5235,9 @@ DROP TABLE products CASCADE;
   
 
   
-   For user-defined functions, PostgreSQL tracks
-   dependencies associated with a function's externally-visible properties,
+   For a user-defined function or procedure whose body is defined as a string
+   literal, PostgreSQL tracks
+   dependencies associated with the function's externally-visible properties,
    such as its argument and result types, but not dependencies
    that could only be known by examining the function body.  As an example,
    consider this situation:
@@ -5264,6 +5265,23 @@ CREATE FUNCTION get_color_note (rainbow) RETURNS text AS
    table is missing, though executing it would cause an error; creating a new
    table of the same name would allow the function to work again.
   
+
+  
+   On the other hand, for a SQL-language function or procedure whose body
+   is written in SQL-standard style, the body is parsed at function
+   definition time and all dependencies recognized by the parser are
+   stored.  Thus, if we write the function above as
+
+
+CREATE FUNCTION get_color_note (rainbow) RETURNS text
+BEGIN ATOMIC
+  SELECT note FROM my_colors WHERE color = $1;
+END;
+
+
+   then the function's dependency on the my_colors
+   table will be known and enforced by DROP.
+