| From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Odd procedure resolution |
| Date: | 2018-03-23 14:42:51 |
| Message-ID: | CAFjFpRdZ61uKWRQw=ypzb3wpyVno6=btzRXtQEqiVm1mgotd8w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 23, 2018 at 7:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julian Markwort | 2018-03-23 14:45:15 | Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full |
| Previous Message | Peter Eisentraut | 2018-03-23 14:36:41 | Re: PATCH: Configurable file mode mask |