Обсуждение: Deprecating postfix and factorial operators in PostgreSQL 13
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
Вложения
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
> 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
Вложения
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
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
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
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
> 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
Вложения
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
> 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