Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 17, 2020 at 2:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Glad you like 'em ;-). Do you have an opinion about what to do
>> with the operator tables --- ie do we need a column with the operator
>> name at the left?
> Well, if the first row says date + date -> date, then I don't think we
> also need another column to say that we're talking about +
> Seems redundant.
Well, sure it's redundant, the same way an index is redundant.
Question is whether it makes it easier to find what you're after.
Comparing this to what is in table 9.30 as of HEAD [1], it does
seem like the operator column in the latter is a bit busy/redundant.
Perhaps it'd be less so if we used the morerows trick to have only
one occurrence of each operator name in the first column. But that
would be a little bit of a pain to maintain, so I'm not sure it's
worth the trouble.
Another advantage of handling functions and operators in exactly
the same format is that we won't need to do something weird for
tables 9.9 and 9.11, which include both.
For the moment I'll press on without including that column; we can
add it later without a huge amount of pain if we decide we want it.
On the other point of dispute about the operator tables: for the
moment I'm leaning towards keeping the text descriptions. Surveying
the existing tables, the *only* two that lack text descriptions now
are this one and the as-yet-unnumbered table in 9.1 for AND/OR/NOT.
(Actually, that one calls itself a truth table not an operator
definition table, so maybe we should leave it alone.) While there
is a reasonable argument that 9.1 Comparison Operators' descriptions
are all obvious, it's hard to make that argument for any other tables.
So I think the fact that 9.30 lacked such up to now is an aberration
not a good principle to follow. Even in 9.30, the fact that, say,
date + integer interprets the integer as so-many-days isn't really
so blindingly obvious that it doesn't need documented. In another
universe we might've made that count as seconds and had the result
type be timestamp, the way it works for date + interval.
regards, tom lane
[1] https://www.postgresql.org/docs/devel/functions-datetime.html
