Re: Odd procedure resolution

On Sat, May 19, 2018 at 12:51 AM, Robert Haas wrote: > On Thu, May 17, 2018 at 4:10 PM, Peter Eisentraut > wrote: >> I think I have made a mistake here. I was reading in between the lines >> of a competitor's documentation that they have

Re: Odd procedure resolution

On Thu, May 17, 2018 at 4:10 PM, Peter Eisentraut wrote: > I think I have made a mistake here. I was reading in between the lines > of a competitor's documentation that they have functions and procedures > in different name spaces, which made me re-read the SQL

Re: Odd procedure resolution

On 5/17/18 16:54, Tom Lane wrote: > TBH, this is several months too late for v11. Maybe, but ... You're talking about a > really fundamental redesign, at least if it's done right and not as a > desperate last-minute hack (which is what this looks like). The points > you make here are just the

Re: Odd procedure resolution

Peter Eisentraut writes: > I think I have made a mistake here. I was reading in between the lines > of a competitor's documentation that they have functions and procedures > in different name spaces, which made me re-read the SQL standard, which > appears to

Re: Odd procedure resolution

On Wed, May 16, 2018 at 03:37:18PM -0400, Robert Haas wrote: > On Wed, May 16, 2018 at 3:29 PM, Tom Lane wrote: > > BTW, we seem to have some confusion here already: > > > > regression=# create function foo(int) returns int as 'select $1' language > > sql; > > CREATE FUNCTION

Re: Odd procedure resolution

On Wed, May 16, 2018 at 3:29 PM, Tom Lane wrote: > My opinion remains unchanged. If you're unhappy about the system > confusing procedure foo(int) and function foo(real), maybe the answer > is to not overload the name "foo" with such enthusiasm. But putting > kluges into

Re: Odd procedure resolution

Robert Haas writes: > On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat > wrote: >> On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote: >>> ISTM this patch effectively proposes to make procedures have their own >>>

Re: Odd procedure resolution

On Fri, Mar 23, 2018 at 10:42 AM, Ashutosh Bapat wrote: > On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote: >> Ashutosh Bapat writes: >>> Incidently the fix looks quite simple. See patch attached. >> >> ISTM

Re: Odd procedure resolution

On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane wrote: > Ashutosh Bapat writes: >> Incidently the fix looks quite simple. See patch attached. > > ISTM this patch effectively proposes to make procedures have their own > namespace yet still live in

Re: Odd procedure resolution

Ashutosh Bapat writes: > Incidently the fix looks quite simple. See patch attached. ISTM this patch effectively proposes to make procedures have their own namespace yet still live in pg_proc. That is the worst of all possible worlds IMO. Somewhere early in this

Re: Odd procedure resolution

Incidently the fix looks quite simple. See patch attached. With this patch we have a diffs in create_procedure test like CALL random(); -- error ! ERROR: random() is not a procedure LINE 1: CALL random(); ^ ! HINT: To call a function, use SELECT. CREATE FUNCTION

Odd procedure resolution

Hi, Consider following scenario create function foo(a int) returns integer as $$begin return a; end; $$ language plpgsql; create procedure foo(a float) as $$begin end; $$ language plpgsql; call foo(1); psql:proc_func_resolution.sql:8: ERROR: foo(integer) is not a procedure LINE 1: call foo(1);