Re: Mark deprecated operators as such in their comments? - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Mark deprecated operators as such in their comments?
Date
Msg-id AANLkTi=GHbOm39xPFRxqCcwABuA35XJ=TmRiUY88RjDc@mail.gmail.com
Whole thread Raw
In response to Mark deprecated operators as such in their comments?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Mark deprecated operators as such in their comments?
List pgsql-hackers
On Thu, Mar 3, 2011 at 3:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 1. Do people like the idea of marking obsolete operator names this
> way?  If so, exactly how to mark them?  We could try to add
> "(deprecated, ...)" at the end of the existing description, or just
> replace the description completely.  In some of these cases the
> existing description is pretty long, making the latter attractive.

Marking deprecated legacy names is nice. I hate as a programmer being
confronted with multiple identical-sounding options and not knowing
which one I should be using.


> 2. Given that we do #1, is it really a good idea to generate the
> boilerplate comments automatically?  The argument I can see against it
> is that right now there's a pretty simple coding rule "every pg_proc.h
> entry should have a comment".  This is less confusing than "every
> pg_proc.h entry should have a comment, except those that are linked to
> pg_operator entries and aren't meant to be used directly".  I'm not
> sure that argument outweighs "writing the boilerplate comment is a
> PITA", but I'm not sure it doesn't either.
>

A way out might be to have a token in the DESCR like "-" or "$opr" or
something which indicates "substitute the default description here".

But I'm not sure it's worth bothering. Filling in the description
field is hardly the most annoying part of adding pg_proc entries for
operators. If we could move most or all of the entries to an SQL file
so that we didn't have to deal with commutator and negator oids and
all that, that would save a lot of pain.
--
greg


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Quick Extensions Question
Next
From: Kohei Kaigai
Date:
Subject: Re: sepgsql contrib module