Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?)
Date
Msg-id 9858.1096843064@sss.pgh.pa.us
Whole thread Raw
In response to Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?)  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> The reason the "char" arithmetic operators are dangerous is that they are
>> the only ones of those names in the STRING type category.

> What would happen if "char" were just removed from the STRING type category?

What other category would you put it in?  The I/O behavior of "char"
is certainly not very conducive to thinking of it as storing integral
values, anyway.

> Or alternatively if it were broken out into two data types, "char" which
> didn't have these operators, and int1 which only had these operators and not
> all the string operators?

I don't have an objection in principle to an int1 datatype, but there
are a couple of practical objections; primarily that that looks way too
much like a new feature for this point in the 8.0 cycle.  (I seem to
recall having once had concerns about unexpected side effects from
adding another set of overloaded operators to the NUMERIC category, too;
but I'm not sure if that's still relevant given the resolution-rule
changes we've made in the last couple releases.)

Even with an int1 datatype, I'm not sure it makes sense to provide
arithmetic operators specifically for the type, as opposed to providing
implicit coercions to "integer" and letting the actual arithmetic
happen at integer width.
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: External Tabular Data Via SQL
Next
From: Bruno Wolff III
Date:
Subject: Re: Checking for overflow of integer arithmetic