Tom Lane <tgl@sss.pgh.pa.us> writes:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> What I'm inclined to do with these is change pg_proc.h but not force
> >> an initdb. Does anyone want to argue for an initdb to force it to be
> >> fixed in 8.0? We've lived with the wrong labelings for some time now
> >> without noticing, so it doesn't seem like a serious enough bug to
> >> force a post-beta initdb ... to me anyway.
>
> > I'd prefer if all users of 8.0 were guaranteed to have the same catalog.
>
> Well, there's something to be said for that viewpoint too. Anyone else
> feel the same?
I would wonder about any users that are happily using beta3 with test data and
upgrade to 8.0 without any problems but at some point later have trouble
restoring from a pg_dump.
> Specifically I want to remove these operators:
>
> oid | oid | oprresult
> -----+-------------------+-----------
> 635 | +("char","char") | "char"
> 636 | -("char","char") | "char"
> 637 | *("char","char") | "char"
> 638 | /("char","char") | "char"
> ...
> 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?
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?
It does seem like having a fixed size 1 byte integer data type would be
something appealing. Personally I find a lot of demand in my database models
for status flags that have very few possible states (often only two but I
don't want to limit myself with a boolean and booleans don't behave nicely
with any other application language since they return 't' and 'f'). I could
easily see some very large table where someone wants to store lots of small
integers that need some arithmetic capabilities.
--
greg
