From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Sergey Cherkashin <s(dot)cherkashin(at)postgrespro(dot)ru>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Subject: | Re: output columns of \dAo and \dAp |
Date: | 2020-07-07 21:02:02 |
Message-ID: | 20200707210202.GA27355@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sergey, Nikita, Alexander, if you can please see this thread and propose
a solution, that'd be very welcome.
On 2020-Jun-06, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> > I'm also wondering whether this is fully correct. Would it be possible for the
> > argument types of the operator/function to differ from the left arg/right arg
> > types? (Perhaps binary compatible?)
>
> pg_amop.h specifies that
>
> * The primary key for this table is <amopfamily, amoplefttype, amoprighttype,
> * amopstrategy>. amoplefttype and amoprighttype are just copies of the
> * operator's oprleft/oprright, ie its declared input data types.
>
> Perhaps it'd be a good idea for opr_sanity.sql to verify that, since
> it'd be an easy thing to mess up in handmade pg_amop entries. But
> at least for the foreseeable future, there's no reason for \dAo to show
> amoplefttype/amoprighttype separately.
>
> I agree that \dAo ought to be showing amopstrategy; moreover that ought
> to be much higher in the sort key than it is. Also, if we're not going
> to show amoppurpose, then the view probably ought to hide non-search
> operators altogether. It is REALLY misleading to not distinguish search
> and ordering operators.
>
> The situation is different for pg_amproc: if you look for discrepancies
> you will find plenty, since in many cases a support function's signature
> has little to do with what types it is registered under. Perhaps it'd be
> worthwhile for \dAp to show the functions as regprocedure in addition to
> showing amproclefttype/amprocrighttype explicitly. In any case, I think
> it's rather misleading for \dAp to label amproclefttype/amprocrighttype as
> "Left arg type" and "Right arg type", because for almost everything except
> btree/hash, that's not what the support function's arguments actually are.
> Perhaps names along the lines of "Registered left type" and "Registered
> right type" would put readers in a better frame of mind to understand
> the entries.
>
> regards, tom lane
>
>
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-07-07 21:03:16 | Re: Default setting for enable_hashagg_disk (hash_mem) |
Previous Message | Dave Cramer | 2020-07-07 20:53:53 | Re: Binary support for pgoutput plugin |