Re: Getting rid of SQLValueFunction - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Getting rid of SQLValueFunction
Date
Msg-id Y1ITPwvYTNac3xvn@paquier.xyz
Whole thread Raw
In response to Re: Getting rid of SQLValueFunction  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Getting rid of SQLValueFunction  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Oct 20, 2022 at 11:10:22PM -0400, Tom Lane wrote:
> The entire point of SQLValueFunction IMO was to hide the underlying
> implementation(s).  Replacing it with something that leaks
> implementation details does not seem like a step forward.

Hmm..  Okay, thanks.  So this just comes down that I am going to need
one different pg_proc entry per SQL keyword, then, or this won't fly
far.  For example, note that on HEAD or with the patch, a view with a
SQL keyword in a FROM clause translates the same way with quotes
applied in the same places, as of:
=# create view test as select (SELECT * FROM CURRENT_USER) as cu;
CREATE VIEW
=# select pg_get_viewdef('test', true);
                           pg_get_viewdef
---------------------------------------------------------------------
  SELECT ( SELECT "current_user"."current_user"                     +
            FROM CURRENT_USER "current_user"("current_user")) AS cu;
(1 row)

A sticky point is that this would need the creation of a pg_proc entry
for "user" which is a generic word, or a shortcut around
FigureColnameInternal().  The code gain overall still looks appealing
in the executor, even if we do all that and the resulting backend code
gets kind of nicer and easier to maintain long-term IMO.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Getting rid of SQLValueFunction
Next
From: Justin Pryzby
Date:
Subject: Re: Cygwin cleanup