Peter Eisentraut writes:
> On 08.06.21 01:10, Tom Lane wrote:
>> Here is said update (rolled up into one patch this time; maybe that will
>> avoid the apply problems you had).
> This patch looks good to me.
Thanks for reviewing!
> A minor comment: You changed the docs in some places like this:
On 08.06.21 01:10, Tom Lane wrote:
I wrote:
Hmm, these are atop HEAD from a week or so back. The cfbot seems to
think they still apply. In any case, I was about to spend some effort
on the docs, so I'll post an updated version soon (hopefully today).
Here is said update (rolled up into one
I wrote:
> Hmm, these are atop HEAD from a week or so back. The cfbot seems to
> think they still apply. In any case, I was about to spend some effort
> on the docs, so I'll post an updated version soon (hopefully today).
Here is said update (rolled up into one patch this time; maybe that will
Peter Eisentraut writes:
> On 04.06.21 23:07, Tom Lane wrote:
>> 0001 is the same patch I posted earlier, 0002 is a delta to enable
>> handling ALTER/DROP per spec.
> I checked these patches. They appear to match what was talked about. I
> didn't find anything surprising. I couldn't apply
On 04.06.21 23:07, Tom Lane wrote:
I wrote:
It would likely not be very hard to fix pg_dump to include explicit
IN markers. I don't think this results in a compatibility problem
for existing dumps, since they won't be taken from databases in
which there are procedures with OUT arguments.
I wrote:
> It would likely not be very hard to fix pg_dump to include explicit
> IN markers. I don't think this results in a compatibility problem
> for existing dumps, since they won't be taken from databases in
> which there are procedures with OUT arguments.
Actually, all we have to do to fix
Peter Eisentraut writes:
> On 02.06.21 02:04, Tom Lane wrote:
>>> It's possible that we could revert proargtypes and still accommodate
>>> the spec's definition for ALTER/DROP ROUTINE/PROCEDURE. I'm imagining
>>> some rules along the line of:
>>> 1. If arg list contains any parameter modes, then
On 03.06.21 23:29, Tom Lane wrote:
Peter Eisentraut writes:
On 02.06.21 02:04, Tom Lane wrote:
Hmm, actually we could make step 2 a shade tighter: if a candidate
routine is a function, match against proargtypes. If it's a procedure,
match against coalesce(proallargtypes, proargtypes). If we
Peter Eisentraut writes:
> On 03.06.21 22:21, Tom Lane wrote:
>> An example is that (AFAICT) the spec allows having both
>> create procedure divide(x int, y int, OUT q int) ...
>> create procedure divide(x int, y int, OUT q int, OUT r int) ...
>> which I want to reject because they have
On 03.06.21 22:21, Tom Lane wrote:
Once you do, you'll possibly notice that PG's rules for which combinations
of signatures are allowed are different from the spec's. I believe that
we're largely more generous than the spec, but there are a few cases where
this proposal isn't. An example is
Peter Eisentraut writes:
> On 02.06.21 02:04, Tom Lane wrote:
>> Hmm, actually we could make step 2 a shade tighter: if a candidate
>> routine is a function, match against proargtypes. If it's a procedure,
>> match against coalesce(proallargtypes, proargtypes). If we find
>> multiple matches,
On 6/3/21 4:50 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Not sure I follow the "other datatypes" bit. Are you saying the spec
>> won't let you have this?:
>> create procedure divide(x int, y int, OUT q int);
>> create procedure divide(x int, y int, OUT q float);
> In fact it
On 02.06.21 02:04, Tom Lane wrote:
I wrote:
It's possible that we could revert proargtypes and still accommodate
the spec's definition for ALTER/DROP ROUTINE/PROCEDURE. I'm imagining
some rules along the line of:
1. If arg list contains any parameter modes, then it must be PG
syntax, so
Andrew Dunstan writes:
> Not sure I follow the "other datatypes" bit. Are you saying the spec
> won't let you have this?:
> create procedure divide(x int, y int, OUT q int);
> create procedure divide(x int, y int, OUT q float);
In fact it won't, because the spec's rule is simply "you
On 6/3/21 4:21 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> So AIUI your suggestion is that ALTER/DROP ROUTINE will look for an
>> ambiguity. If it doesn't find one it proceeds, otherwise it complains in
>> which case the user will have to fall back to ALTER/DROP
>> FUNCTION/PROCEDURE. Is
Andrew Dunstan writes:
> So AIUI your suggestion is that ALTER/DROP ROUTINE will look for an
> ambiguity. If it doesn't find one it proceeds, otherwise it complains in
> which case the user will have to fall back to ALTER/DROP
> FUNCTION/PROCEDURE. Is that right? It seems a reasonable approach,
On 6/3/21 2:29 PM, Tom Lane wrote:
> I wrote:
>> Hmm, actually we could make step 2 a shade tighter: if a candidate
>> routine is a function, match against proargtypes. If it's a procedure,
>> match against coalesce(proallargtypes, proargtypes). If we find
>> multiple matches, raise ambiguity
I wrote:
> Hmm, actually we could make step 2 a shade tighter: if a candidate
> routine is a function, match against proargtypes. If it's a procedure,
> match against coalesce(proallargtypes, proargtypes). If we find
> multiple matches, raise ambiguity error.
Where do we stand on this topic?
I wrote:
> It's possible that we could revert proargtypes and still accommodate
> the spec's definition for ALTER/DROP ROUTINE/PROCEDURE. I'm imagining
> some rules along the line of:
> 1. If arg list contains any parameter modes, then it must be PG
> syntax, so interpret it according to our
Peter Eisentraut writes:
> So while I understand the argument of
> - Function signatures should work consistently with procedure signatures.
> I find the arguments of
> - Procedure signatures should match the SQL standard, and
> - Signature for invoking should match signature for calling.
> a
On 31.05.21 22:25, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
I don't see that.
It's under CREATE PROCEDURE. 11.60 SR 20 says
Oh... just noticed something else relevant to this discussion: SR 13
in the same section saith
13) If R is an SQL-invoked function, then no
in
On 5/31/21 4:25 PM, Tom Lane wrote:
>
> Oh... just noticed something else relevant to this discussion: SR 13
> in the same section saith
>
> 13) If R is an SQL-invoked function, then no
> in NPL shall contain a .
>
> In other words, the spec does not have OUT or INOUT parameters for
>
"David G. Johnston" writes:
> When this discussion concludes a review of the compatibility sections of
> the create/drop “routine” reference pages would be appreciated.
Good idea, whichever answer we settle on. But it's notable that
the existing text gives no hint that the rules are different
On Monday, May 31, 2021, Laurenz Albe 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
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
I wrote:
> Peter Eisentraut writes:
>> I don't see that.
> It's under CREATE PROCEDURE. 11.60 SR 20 says
Oh... just noticed something else relevant to this discussion: SR 13
in the same section saith
13) If R is an SQL-invoked function, then no
in NPL shall contain a .
In other words,
Peter Eisentraut writes:
> On 26.05.21 19:28, Tom Lane wrote:
>> Why? If it actually works that way right now, I'd maintain
>> strenously that it's broken. The latter should be referring
>> to a procedure with two IN arguments. Even if the SQL spec
>> allows fuzziness about that, we cannot
On 26.05.21 19:28, Tom Lane wrote:
Peter Eisentraut writes:
AFAICT, your patch does not main the property that
CREATE PROCEDURE p1(OUT int, OUT int)
corresponds to
DROP PROCEDURE p1(int, int)
which would be bad.
Why? If it actually works that way right now, I'd maintain
Here's a stripped-down patch that drops the change in what should be
in CALL argument lists, and just focuses on reverting the change in
pg_proc.proargtypes and the consequent mess for ALTER/DROP ROUTINE.
I spent some more effort on the docs, too.
regards, tom lane
diff
Peter Eisentraut writes:
> AFAICT, your patch does not main the property that
> CREATE PROCEDURE p1(OUT int, OUT int)
> corresponds to
> DROP PROCEDURE p1(int, int)
> which would be bad.
Why? If it actually works that way right now, I'd maintain
strenously that it's broken. The
On 25.05.21 22:21, Tom Lane wrote:
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
Robert Haas writes:
> On Tue, May 25, 2021 at 3:10 PM Tom Lane 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
On Tue, May 25, 2021 at 3:10 PM Tom Lane wrote:
> No, you misunderstand my proposal. The thing that I most urgently
> want to do is to prevent that situation from ever arising, by not
> allowing those two procedures to coexist, just as you can't have
> two functions with such signatures.
>
> If
Robert Haas writes:
> I'm also concerned about the behavior here. I noticed it when this
> commit went in, and it seemed concerning to me then, and it still
> does. Nevertheless, I'm not convinced that your proposal is an
> improvement. Suppose we have foo(int, out int) and also foo(int).
> Then,
Peter Eisentraut writes:
> On 25.05.21 17:20, Tom Lane wrote:
>> I don't really see how you can argue that the existing behavior is
>> more spec-compliant than what I'm suggesting. What I read in the spec
>> (SQL:2021 10.4 SR 9) h) iii) 1)) is
>> 1) If Pi is an output SQL parameter, then XAi
On Tue, May 25, 2021 at 2:20 PM Tom Lane wrote:
> Just to enlarge on that point a bit:
>
> regression=# create function foo(int, out int) language sql
> regression-# as 'select $1';
> CREATE FUNCTION
> regression=# create procedure foo(int, out int) language sql
> regression-# as 'select $1';
>
I wrote:
> * The rules for how to identify a target routine in ALTER, DROP,
> etc are different for functions and procedures. That's especially
> nasty in ALTER/DROP ROUTINE, where we don't have a syntax cue
> as to whether or not to ignore OUT parameters.
Just to enlarge on that point a bit:
On 25.05.21 17:20, Tom Lane wrote:
I don't really see how you can argue that the existing behavior is
more spec-compliant than what I'm suggesting. What I read in the spec
(SQL:2021 10.4 SR 9) h) iii) 1)) is
1) If Pi is an output SQL parameter, then XAi shall be a .
(where more or less
Peter Eisentraut writes:
> On 24.05.21 02:01, Tom Lane wrote:
>>> I think we ought to fix this so that OUT-only arguments are ignored
>>> when calling from SQL not plpgsql.
> I don't understand why you want to change this. The argument resolution
> of CALL is specified in the SQL standard; we
On 24.05.21 02:01, Tom Lane wrote:
I wrote:
I think we ought to fix this so that OUT-only arguments are ignored
when calling from SQL not plpgsql.
I'm working on a patch to make it act that way. I've got some issues
yet to fix with named arguments (which seem rather undertested BTW,
since
I wrote:
>> I think we ought to fix this so that OUT-only arguments are ignored
>> when calling from SQL not plpgsql.
Here's a draft patch for that. The docs probably need some more
fiddling, but I think the code is in good shape. (I'm unsure about
the JDBC compatibility issue, and would
Andrew Dunstan writes:
> On 5/23/21 8:01 PM, Tom Lane wrote:
>> Before I spend too much time on it though, I wanted to mention that
>> it includes undoing 2453ea142's decision to include OUT arguments
>> in pg_proc.proargtypes for procedures (but not for any other kind of
>> routine). I thought
On 5/23/21 8:01 PM, Tom Lane wrote:
> I wrote:
>> I think we ought to fix this so that OUT-only arguments are ignored
>> when calling from SQL not plpgsql.
> I'm working on a patch to make it act that way. I've got some issues
> yet to fix with named arguments (which seem rather undertested
I wrote:
> I think we ought to fix this so that OUT-only arguments are ignored
> when calling from SQL not plpgsql.
I'm working on a patch to make it act that way. I've got some issues
yet to fix with named arguments (which seem rather undertested BTW,
since the patch is passing check-world even
čt 20. 5. 2021 v 19:53 odesílatel Tom Lane napsal:
> I'm not too happy with this:
>
> regression=# create procedure p1(out x int) language plpgsql
> regression-# as 'begin x := 42; end';
> CREATE PROCEDURE
>
> regression=# call p1();
> ERROR: procedure p1() does not exist
> LINE 1: call p1();
>
I'm not too happy with this:
regression=# create procedure p1(out x int) language plpgsql
regression-# as 'begin x := 42; end';
CREATE PROCEDURE
regression=# call p1();
ERROR: procedure p1() does not exist
LINE 1: call p1();
^
HINT: No procedure matches the given name and argument
46 matches
Mail list logo
