Re: [BUGS] Bug #513: union all changes char(3) column definition
От | Tom Lane |
---|---|
Тема | Re: [BUGS] Bug #513: union all changes char(3) column definition |
Дата | |
Msg-id | 28079.1006402117@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] Bug #513: union all changes char(3) column definition (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [BUGS] Bug #513: union all changes char(3) column definition
|
Список | 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 по дате отправления: