Re: [BUGS] Bug #513: union all changes char(3) column definition

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Bug #513: union all changes char(3) column definition
Date: 2001-11-22 17:21:17
Message-ID: Pine.LNX.4.30.0111221803230.766-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Tom Lane writes:

> The argument here is about how much intelligence it's reasonable to
> expect the system to have. It's very clearly not feasible to derive
> a length limit automagically in every case. How hard should we try?

I would like to know what Proprietary database #1 does with

CREATE TABLE one ( a bit(6) );
INSERT INTO one VALUES ( b'101101' );
CREATE TABLE two ( b bit(4) );
INSERT INTO two VALUES ( b'0110' );
CREATE TABLE three AS SELECT a FROM one UNION SELECT b FROM two;

According to SQL92, clause 9.3, the result type of the union is bit(6).
However, it's not possible to store a bit(4) value into a bit(6) field.
Our current solution, "bit(<nothing>)" is even worse because it has no
real semantics at all (but you can store bit(<anything>) in it,
interestingly).

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message pgsql-bugs 2001-11-23 10:20:46 Bug #519: Bug in order by clausule
Previous Message Kostis 2001-11-22 15:04:50 UPDATE fails on large table

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-11-22 17:21:30 Re: Diff/Patch integration -> SQL cvs clone
Previous Message Bruce Momjian 2001-11-22 17:18:33 Re: Diff/Patch integration -> SQL cvs clone