From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CALL versus procedures with output-only arguments |
Date: | 2021-06-01 01:48:07 |
Message-ID: | CAKFQuwbgMGT=5q-+8vACQL3i6GVrVD9P4omTpwk192SRW7ryTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday, May 31, 2021, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-06-01 02:06:53 | Re: Different compression methods for FPI |
Previous Message | Michael Paquier | 2021-06-01 01:41:09 | Re: Alias collision in `refresh materialized view concurrently` |