Re: CALL versus procedures with output-only arguments

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: CALL versus procedures with output-only arguments
Дата
Msg-id CAKFQuwbgMGT=5q-+8vACQL3i6GVrVD9P4omTpwk192SRW7ryTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CALL versus procedures with output-only arguments  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: CALL versus procedures with output-only arguments  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Monday, May 31, 2021, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Mon, 2021-05-31 at 15:55 -0400, Tom Lane wrote:
> > If I have two procedures
> > p1(IN int, IN int, OUT int, OUT int)
> > p1(OUT int, OUT int)
> > then a DROP, or ALTER, or GRANT, etc. on p1(int, int) should operate on
> > the second one in a spec-compliant implementation, but you propose to
> > have it operate on the first one.  That kind of discrepancy would be
> > really bad to have.
>
> We already have that situation for functions.  I think having procedures
> work differently from functions is much worse than your complaint here;
> and I do not see why being spec-compliant for one case when we are not
> for the other is a good situation to be in.

+1

When this discussion concludes a review of the compatibility sections of the create/drop “routine” reference pages would be appreciated.

I agree that being consistent with our long-standing function behavior is more important than being standards compliant.  FWIW this being DDL lessens any non-compliance reservations I may have.

David J.

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Alias collision in `refresh materialized view concurrently`
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Different compression methods for FPI