Re: Deprecating postfix and factorial operators in PostgreSQL 13

> 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 interpretation in the standard catalogs.  In both cases, the scanner cannot know the types of the undecorated arguments and assigns default types (integer and unknown, respectively), which get resolved later to match the only types accepted by the operator ('int8' for !, and 'jsonb,text' for ?).

The drop operator example has been left, though altered to include the adjective "deprecated".  Robert mentions that the entire example could simply be dropped now, and I agree with that, but it also makes sense to me to drop the example in 14, 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.