Thread: Deprecating postfix and factorial operators in PostgreSQL 13

Deprecating postfix and factorial operators in PostgreSQL 13

From
Mark Dilger
Date:
Hackers,

Over in [1] we have been discussing the deprecation of postfix operators, with the general consensus that deprecation
warningsshould be included in this upcoming release and postfix operator support should be removed in PostgreSQL 14.
Sincenot all people who follow -hackers will necessarily have been following that thread, I am creating this new
thread,with a patch which adds the deprecation notices, for your consideration. 

The only postfix operator we ship in the standard catalogs is the factorial operator (!), which is deprecated by this
patch.

The standard catalogs also include a prefix factorial operator (!!) which has been deprecated since 2011.

The deprecation warnings included in this patch warn that postfix operator support, along with both postfix ! and
prefix!! factorial operators, will be removed in PostgreSQL 14. 

Some of the deprecation verbiage supplied by John Naylor, some by me:



[1]
https://www.postgresql.org/message-id/flat/20200519145449.GN13712%40tamriel.snowman.net#34294baed8757c8e078550b9ba80081d

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




Attachment

Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Tom Lane
Date:
Mark Dilger <mark.dilger@enterprisedb.com> writes:
> The deprecation warnings included in this patch warn that postfix operator support, along with both postfix ! and
prefix!! factorial operators, will be removed in PostgreSQL 14. 

The operator docs should say "use factorial() instead", or words to
that effect.

            regards, tom lane



Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Mark Dilger
Date:

> On Aug 27, 2020, at 9:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mark Dilger <mark.dilger@enterprisedb.com> writes:
>> The deprecation warnings included in this patch warn that postfix operator support, along with both postfix ! and
prefix!! factorial operators, will be removed in PostgreSQL 14. 
>
> The operator docs should say "use factorial() instead", or words to
> that effect.
>
>             regards, tom lane

Yes, that is better.  Attached.



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




Attachment

Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
John Naylor
Date:
Hi Mark,

-{ oid => '111',
+{ oid => '111', descr => 'factorial',

I see that opr_sanity fails without something here. We explicitly
don't have descriptions of functions that implement deprecated
operators (see setup_description() in initdb.c), but in all other
cases, there are also supported operators present. Technically, it's
not the same entry as the sql-callable function (1376), so it might be
better to try to match the other operator functions and say
"implementation of deprecated ! and !! operators".

For typeconv.sgml, it looks like in v14 we'll just have a different
operator entirely for the example, so ideally we would backpatch that
change for v13. What you have is good enough in a pinch, though.

--
John Naylor                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Robert Haas
Date:
On Thu, Aug 27, 2020 at 1:07 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
> Yes, that is better.  Attached.

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.

That being said, the changes to typeconv.sgml and drop_operator.sgml
seem like improvements, so I'd keep those.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Tom Lane
Date:
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?

            regards, tom lane



Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Robert Haas
Date:
On Fri, Aug 28, 2020 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?

Hmm, that's an idea. I think it would be reasonable to rewrite the
typeconv.sgml one, but the one in drop_operator.sgml seems like it
could just be dropped. Its only purpose seems to be to demonstrate how
to drop a right-unary operator vs. a left-unary operator, but I
venture to guess that anyone smart enough to make any sort of
effective use of DROP OPERATOR could probably draw the necessary
inferences anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Mark Dilger
Date:

> 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

Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Tom Lane
Date:
Mark Dilger <mark.dilger@enterprisedb.com> writes:
> [ v3-0001-Adding-deprecation-notices.patch ]

Pushed with some fiddling.

We previously found that adding id tags to <entry> constructs in the
function lists didn't work in PDF output [1].  Your patch did build
a PDF without warnings for me, which is odd --- apparently we changed
something since April?  But the links didn't lead to quite the right
place, so the conclusion that there's something broken with that still
holds.  I made it look like the existing usages for encode() and decode().

I did not like your choice of "jsonb ? text" for the typeconv example
at all, primarily because it introduces a host of distractions for anyone
who's not already quite familiar with both JSON and that operator.
After some digging around I found the |/ (square root) operator, which
likewise has just one instance, and it's something familiar enough that
most readers probably won't be slowed down by trying to figure out what
it does.  Also, this more nearly covers the territory of the original
example, namely auto-casting an integer constant to something else.
There are later examples covering unknown-type literals, so we don't
need to address that scenario in this one.

I also found another example that depends on the ! operator, in the
operator precedence discussion.  I concluded after study that the
particular case it's on about only arises for postfix operators,
so I just got rid of that example in favor of a generalized mention
that you should use parentheses to override operator precedence.

I concluded that there's not much point in touching drop_operator.sgml
at all yet.  I don't think labeling ! as deprecated as adding anything
to that example, and besides there's another example that will also need
to be changed.

            regards, tom lane

[1] https://www.postgresql.org/message-id/32159.1586738304%40sss.pgh.pa.us



Re: Deprecating postfix and factorial operators in PostgreSQL 13

From
Mark Dilger
Date:

> On Aug 30, 2020, at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mark Dilger <mark.dilger@enterprisedb.com> writes:
>> [ v3-0001-Adding-deprecation-notices.patch ]
>
> Pushed with some fiddling.

Thanks!

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