Re: Deprecating postfix and factorial operators in PostgreSQL 13 - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Deprecating postfix and factorial operators in PostgreSQL 13
Date
Msg-id 0EAB2286-69A8-4CB0-91E0-16EBB3749812@enterprisedb.com
Whole thread Raw
In response to Re: Deprecating postfix and factorial operators in PostgreSQL 13  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Deprecating postfix and factorial operators in PostgreSQL 13  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> On Aug 28, 2020, at 8:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
>> So, in this version, there are six copies of the deprecation notice
>> John wrote, rather than just one. Maybe we need more than one, but I
>> doubt we need six. I don't think the CREATE OPERATOR documentation
>> needs to mention this both when first introducing the concept and then
>> again when defining right_type; the former seems sufficient. I don't
>> think xoper.sgml needs these changes either; they interrupt the flow
>> of the narrative and I don't think this is where anyone would look for
>> a deprecation notice. I would also argue for dropping the mentions in
>> the docs for ALTER OPERATOR FAMILY and CREATE OPERATOR CLASS, although
>> those seem less clear-cut. Really, CREATE OPERATOR where John had it
>> originally seems like the right place.
>
> Yeah, I agree that there are way too many copies here.  CREATE OPERATOR
> seems sufficient.  It also seems like we should just rewrite the typeconv
> and drop_operator examples to use some other operator.  We'll have
> to do that eventually anyway, so why not now, instead of visiting those
> places twice?

John's deprecation language now only appears in the create operator documentation.

The first typeconv example was based on the (int8 !) operator.  I chose to replace it with and example based on the
(jsonb? text) operator, as the two operators have a relevant similarity.  Both of them are singletons, with only one
interpretationin the standard catalogs.  In both cases, the scanner cannot know the types of the undecorated arguments
andassigns default types (integer and unknown, respectively), which get resolved later to match the only types accepted
bythe operator ('int8' for !, and 'jsonb,text' for ?). 

The drop operator example has been left, though altered to include the adjective "deprecated".  Robert mentions that
theentire example could simply be dropped now, and I agree with that, but it also makes sense to me to drop the example
in14, when the operation it describes is also dropped.  If the committer who picks this up wants to drop that example
now,that's fine, too. 



—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: list of extended statistics on psql
Next
From: Tom Lane
Date:
Subject: Re: list of extended statistics on psql