Re: Deprecating postfix and factorial operators in PostgreSQL 13

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: Deprecating postfix and factorial operators in PostgreSQL 13
Date: 2020-08-30 18:50:07
Message-ID: 3892920.1598813407@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-08-30 21:59:39 Re: Compatible defaults for LEAD/LAG
Previous Message Pavel Stehule 2020-08-30 17:13:31 Re: Row estimates for empty tables