Re: CALL versus procedures with output-only arguments
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-01T01:48:07Z
Lists: 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.
Commits
-
Reconsider the handling of procedure OUT parameters.
- e56bce5d4378 14.0 landed