Re: CALL versus procedures with output-only arguments

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: CALL versus procedures with output-only arguments
Дата
Msg-id 1255142.1621974081@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: CALL versus procedures with output-only arguments  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: CALL versus procedures with output-only arguments  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 25, 2021 at 3:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You're definitely confused, because reversing that choice is *exactly*
>> what I'm on about.  The question of whether SQL-level CALL should act
>> differently from plpgsql CALL is pretty secondary.

> I understood the reverse from the first post on the thread, so perhaps
> it is more that your thinking has developed than that I am confused.

Yeah, the odd behavior of CALL is where I started from, but now I think
the main problem is with the signature (ie, allowing procedures with
signatures that differ only in OUT parameter positions).  If we got
rid of that choice then it'd be possible to document that you should
only ever write NULL for OUT-parameter positions, because the type
of such an argument would never be significant for disambiguation.

We could consider going further and actually enforcing use of NULL,
or inventing some other syntactic placeholder such as the '?' that
Peter was speculating about.  But I'm not sure that that adds much.

Relevant to this is that my proposed patch gets rid of the existing
behavior that such arguments actually get evaluated.  That would
need to be documented, unless we go with the placeholder approach.
But I've not spent time on the documentation yet.

            regards, tom lane



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

Предыдущее
От: Matthias van de Meent
Дата:
Сообщение: Re: Add ZSON extension to /contrib/
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Add ZSON extension to /contrib/