Date: Tue, 7 Jul 2020 17:02:02 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Sergey Cherkashin <s.cherkashin@postgrespro.ru>,
	Nikita Glukhov <n.gluhov@postgrespro.ru>,
	Alexander Korotkov <aekorotkov@gmail.com>
Subject: Re: output columns of \dAo and \dAp
Message-ID: <20200707210202.GA27355@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1698998.1591479248@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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.eisentraut@2ndquadrant.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