From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(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-12-05 21:04:15 |
Message-ID: | 200112052104.fB5L4Ff09941@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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(at)gmx(dot)net
>
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2001-12-06 00:11:33 | Bug #530: index does not work on int8 |
Previous Message | jacques.talbot | 2001-12-04 20:46:28 | Error linking on aix with-tcl |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-12-05 21:04:32 | Re: Minor buglet in update...from (I think) |
Previous Message | Hannu Krosing | 2001-12-05 21:04:01 | Re: Licensing |