From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb_delete not documented |
Date: | 2015-12-07 17:05:55 |
Message-ID: | 5665BC73.1090904@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/06/2015 10:49 PM, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> I see. The reference from pg_operator to pg_proc is by OID rather than
>> function name, so I didn't find them. Is that because the function is
>> overloaded?
> Yeah, I suppose so --- regproc can't resolve overloaded function names.
>
>> It's kind of odd that these are the only operators (at
>> first glance) that are set up like that.
> I think the customary thing when creating functions meant as operator
> support is to give them unique names. These weren't done that way ...
> I wasn't involved, but I wonder whether there was uncertainty as to
> whether these should be documented as functions or operators.
>
>
If we want to require that then perhaps we should have a check for it? I
don't recall the exact reasoning so many months later, but you're
probably right about how it came about.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-12-07 18:06:42 | Re: Foreign join pushdown vs EvalPlanQual |
Previous Message | Jeff Janes | 2015-12-07 17:01:53 | Re: Using quicksort for every external sort run |