Re: [BUGS] Bug #513: union all changes char(3) column definition - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] Bug #513: union all changes char(3) column definition
Date
Msg-id 28079.1006402117@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] Bug #513: union all changes char(3) column definition  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [BUGS] Bug #513: union all changes char(3) column definition
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> However, I don't think creating a bpchar
> with no length is a proper solution.  Should we just punt to text in
> these cases?

How many special cases like that do you want to put into the allegedly
datatype-independent CREATE TABLE code?

If I thought this were the only case then I'd not object ... but it
looks like a slippery slope from here.

And --- it's not like replacing "bpchar" with "text" actually buys us
any useful new functionality.  AFAICS it's just a cosmetic thing.
        regards, tom lane

PS: On the other hand, we might consider attacking the problem from
the reverse direction, ie *removing* code.  For example, if there
weren't redundant || operators for char and varchar, then every ||
operation would yield text, and the example we're looking at would
work the way you want for free.  I've thought for awhile that we
could use a pass through pg_proc and pg_operator to remove some
entries we don't really need.


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: beta3
Next
From: Bruce Momjian
Date:
Subject: Re: [BUGS] Bug #513: union all changes char(3) column definition