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

From Bruce Momjian
Subject Re: [BUGS] Bug #513: union all changes char(3) column definition
Date
Msg-id 200112052104.fB5L4Ff09941@candle.pha.pa.us
Whole thread Raw
In response to Re: [BUGS] Bug #513: union all changes char(3) column definition  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Thread added to TODO.detail.

> 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@gmx.net
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Minor buglet in update...from (I think)
Next
From: Bruce Momjian
Date:
Subject: Re: Security note: MS SQL is current worm vector