Horton

Thread

Commits

  1. Mark factorial operator, and postfix operators in general, as deprecated.

  1. Deprecating postfix and factorial operators in PostgreSQL 13

    Mark Dilger <mark.dilger@enterprisedb.com> — 2020-08-27T16:13:49Z

    Hackers,

Over in [1] we have been discussing the deprecation of postfix operators, with the general consensus that deprecation warnings should be included in this upcoming release and postfix operator support should be removed in PostgreSQL 14.  Since not 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:

  2. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-08-27T16:16:22Z

    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

  3. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Mark Dilger <mark.dilger@enterprisedb.com> — 2020-08-27T17:07:34Z

    
> 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.

  4. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    John Naylor <john.naylor@2ndquadrant.com> — 2020-08-28T08:24:40Z

    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

  5. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Robert Haas <robertmhaas@gmail.com> — 2020-08-28T15:17:12Z

    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

  6. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-08-28T15:56:26Z

    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

  7. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Robert Haas <robertmhaas@gmail.com> — 2020-08-28T16:43:16Z

    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

  8. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Mark Dilger <mark.dilger@enterprisedb.com> — 2020-08-30T16:55:19Z

    
> 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.

  9. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-08-30T18:50:07Z

    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

  10. Re: Deprecating postfix and factorial operators in PostgreSQL 13

    Mark Dilger <mark.dilger@enterprisedb.com> — 2020-08-31T14:25:21Z

    
> 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