Re: row_to_json(), NULL values, and AS

Neil Conway <neil.conway@gmail.com> writes:
> On Fri, Jun 15, 2018 at 7:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (3) As it happens, the column interpretation is chosen when it's
>> ambiguous (cf ParseComplexProjection).
>> 
>> I'm a bit hesitant to muck with this behavior, given that it's stood
>> for ~20 years.  However, if we did want to touch it, maybe the right
>> thing would be to give up the absolutist position that f(x) and x.f
>> are exactly interchangeable.  We could say instead that we prefer the
>> function interpretation if function syntax is used, and the column
>> interpretation if column syntax is used.

> Interesting! Your proposed change seems quite reasonable to me.

Here's a proposed patch for that.  (It needs to be applied over the
fixes in <14497.1529089235@sss.pgh.pa.us>, which are unrelated but
touch some of the same code.)  I didn't add any test cases yet,
but probably it's desirable to have one.

I wrote the doc change on the assumption that we'd sneak this into
v11, but if anyone doesn't want to do that, I'll add it to the next
commitfest instead.

            regards, tom lane

diff --git a/doc/src/sgml/rowtypes.sgml b/doc/src/sgml/rowtypes.sgml
index 3f24293..2f924b1 100644
*** a/doc/src/sgml/rowtypes.sgml
--- b/doc/src/sgml/rowtypes.sgml
*************** SELECT c.somefunc FROM inventory_item c;
*** 441,449 ****
      Because of this behavior, it's unwise to give a function that takes a
      single composite-type argument the same name as any of the fields of
      that composite type.  If there is ambiguity, the field-name
!     interpretation will be preferred, so that such a function could not be
!     called without tricks.  One way to force the function interpretation is
!     to schema-qualify the function name, that is, write

<literal><replaceable>schema</replaceable>.<replaceable>func</replaceable>(<replaceable>compositevalue</replaceable>)</literal>.
     </para>
    </tip>
--- 441,452 ----
      Because of this behavior, it's unwise to give a function that takes a
      single composite-type argument the same name as any of the fields of
      that composite type.  If there is ambiguity, the field-name
!     interpretation will be chosen if field-name syntax is used, while the
!     function will be chosen if function-call syntax is used.  However,
!     <productname>PostgreSQL</productname> versions before 11 always chose the
!     field-name interpretation, unless the syntax of the call required it to
!     be a function call.  One way to force the function interpretation in
!     older versions is to schema-qualify the function name, that is, write

<literal><replaceable>schema</replaceable>.<replaceable>func</replaceable>(<replaceable>compositevalue</replaceable>)</literal>.
     </para>
    </tip>
diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index 21ddd5b..6891cbc 100644
*** a/src/backend/parser/parse_func.c
--- b/src/backend/parser/parse_func.c
*************** static Node *ParseComplexProjection(Pars
*** 49,63 ****
   *    For historical reasons, Postgres tries to treat the notations tab.col
   *    and col(tab) as equivalent: if a single-argument function call has an
   *    argument of complex type and the (unqualified) function name matches
!  *    any attribute of the type, we take it as a column projection.  Conversely
!  *    a function of a single complex-type argument can be written like a
!  *    column reference, allowing functions to act like computed columns.
   *
   *    Hence, both cases come through here.  If fn is null, we're dealing with
!  *    column syntax not function syntax, but in principle that should not
!  *    affect the lookup behavior, only which error messages we deliver.
!  *    The FuncCall struct is needed however to carry various decoration that
!  *    applies to aggregate and window functions.
   *
   *    Also, when fn is null, we return NULL on failure rather than
   *    reporting a no-such-function error.
--- 49,65 ----
   *    For historical reasons, Postgres tries to treat the notations tab.col
   *    and col(tab) as equivalent: if a single-argument function call has an
   *    argument of complex type and the (unqualified) function name matches
!  *    any attribute of the type, we can interpret it as a column projection.
!  *    Conversely a function of a single complex-type argument can be written
!  *    like a column reference, allowing functions to act like computed columns.
!  *
!  *    If both interpretations are possible, we prefer the one matching the
!  *    syntactic form, but otherwise the form does not matter.
   *
   *    Hence, both cases come through here.  If fn is null, we're dealing with
!  *    column syntax not function syntax.  In the function-syntax case,
!  *    the FuncCall struct is needed to carry various decoration that applies
!  *    to aggregate and window functions.
   *
   *    Also, when fn is null, we return NULL on failure rather than
   *    reporting a no-such-function error.
*************** ParseFuncOrColumn(ParseState *pstate, Li
*** 84,89 ****
--- 86,92 ----
      bool        agg_distinct = (fn ? fn->agg_distinct : false);
      bool        func_variadic = (fn ? fn->func_variadic : false);
      WindowDef  *over = (fn ? fn->over : NULL);
+     bool        could_be_projection;
      Oid            rettype;
      Oid            funcid;
      ListCell   *l;
*************** ParseFuncOrColumn(ParseState *pstate, Li
*** 202,237 ****
      }

      /*
!      * Check for column projection: if function has one argument, and that
!      * argument is of complex type, and function name is not qualified, then
!      * the "function call" could be a projection.  We also check that there
!      * wasn't any aggregate or variadic decoration, nor an argument name.
       */
!     if (nargs == 1 && !proc_call &&
!         agg_order == NIL && agg_filter == NULL && !agg_star &&
!         !agg_distinct && over == NULL && !func_variadic && argnames == NIL &&
!         list_length(funcname) == 1)
!     {
!         Oid            argtype = actual_arg_types[0];

!         if (argtype == RECORDOID || ISCOMPLEX(argtype))
!         {
!             retval = ParseComplexProjection(pstate,
!                                             strVal(linitial(funcname)),
!                                             first_arg,
!                                             location);
!             if (retval)
!                 return retval;

!             /*
!              * If ParseComplexProjection doesn't recognize it as a projection,
!              * just press on.
!              */
!         }
      }

      /*
-      * Okay, it's not a column projection, so it must really be a function.
       * func_get_detail looks up the function in the catalogs, does
       * disambiguation for polymorphic functions, handles inheritance, and
       * returns the funcid and type and set or singleton status of the
--- 205,243 ----
      }

      /*
!      * Decide whether it's legitimate to consider the construct to be a column
!      * projection.  For that, there has to be a single argument of complex
!      * type, the function name must not be qualified, and there cannot be any
!      * syntactic decoration that'd require it to be a function (such as
!      * aggregate or variadic decoration, or named arguments).
       */
!     could_be_projection = (nargs == 1 && !proc_call &&
!                            agg_order == NIL && agg_filter == NULL &&
!                            !agg_star && !agg_distinct && over == NULL &&
!                            !func_variadic && argnames == NIL &&
!                            list_length(funcname) == 1 &&
!                            (actual_arg_types[0] == RECORDOID ||
!                             ISCOMPLEX(actual_arg_types[0])));

!     /*
!      * If it's column syntax, check for column projection case first.
!      */
!     if (could_be_projection && is_column)
!     {
!         retval = ParseComplexProjection(pstate,
!                                         strVal(linitial(funcname)),
!                                         first_arg,
!                                         location);
!         if (retval)
!             return retval;

!         /*
!          * If ParseComplexProjection doesn't recognize it as a projection,
!          * just press on.
!          */
      }

      /*
       * func_get_detail looks up the function in the catalogs, does
       * disambiguation for polymorphic functions, handles inheritance, and
       * returns the funcid and type and set or singleton status of the
*************** ParseFuncOrColumn(ParseState *pstate, Li
*** 527,532 ****
--- 533,552 ----
      else
      {
          /*
+          * Not found as a function.  Check for column projection case if
+          * allowed and we didn't do so already.
+          */
+         if (could_be_projection && !is_column)
+         {
+             retval = ParseComplexProjection(pstate,
+                                             strVal(linitial(funcname)),
+                                             first_arg,
+                                             location);
+             if (retval)
+                 return retval;
+         }
+
+         /*
           * Oops.  Time to die.
           *
           * If we are dealing with the attribute notation rel.function, let the