Re: Getting rid of SQLValueFunction

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Getting rid of SQLValueFunction
Дата
Msg-id Y1ITPwvYTNac3xvn@paquier.xyz
обсуждение исходный текст
Ответ на Re: Getting rid of SQLValueFunction  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Getting rid of SQLValueFunction  (Michael Paquier <michael@paquier.xyz>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Getting rid of SQLValueFunction
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Cygwin cleanup