> On Aug 28, 2020, at 8:56 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@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.
v3-0001-Adding-deprecation-notices.patch
Description: Binary data
— Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
