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 functions and procedures
>> in different name spaces, whic
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 standard, which
> appears to suppor
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 ti
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 support that approach.
> So I'm propo
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
> > regression=# cre
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 (some of) the lookup rul
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
>>> namespace yet still live in pg_proc. That is the worst of all possible
>>> worlds IM
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 this patch effectively proposes to make procedures have their own
>> namespace yet still
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 pg_proc. That is the worst of all possible
> worlds IMO
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 patch series, I complained that
p
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 cp_testfunc
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);
12 matches
Mail list logo
