Re: Odd procedure resolution - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Odd procedure resolution
Date
Msg-id CAFjFpRdZ61uKWRQw=ypzb3wpyVno6=btzRXtQEqiVm1mgotd8w@mail.gmail.com
Whole thread Raw
In response to Re: Odd procedure resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Odd procedure resolution  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> 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
> procedures should be in a different namespace and therefore not be kept
> in pg_proc but in some new catalog.  That argument was rejected on the
> grounds that SQL requires them to be in the same namespace, which I
> wasn't particularly sold on, but that's where we are.  If they are in
> the same namespace, though, we have to live with the consequences of
> that, including ambiguity.  Otherwise there will soon be questions
> like "well, why can't I create both function foo(int) and procedure
> foo(int), seeing that there's no question which of them a particular
> statement intends to call?".
>

That question did cross my mind and I think that's a valid question.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: PATCH: Configurable file mode mask
Next
From: Julian Markwort
Date:
Subject: Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full