From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, stiening(at)cannon(dot)astro(dot)umass(dot)edu, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bug #513: union all changes char(3) column definition |
Date: | 2001-11-11 16:49:47 |
Message-ID: | 20117.1005497387@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> CREATE TABLE AS cannot be expected to be able to extract a suitable
>> typmod from complex expressions.
> I don't think that would be entirely unreasonable.
Well, it might not be completely impossible, but I think it's well on
the far side of unreasonable. For *every operator* that produces a
result of any of the typmod-using types, we'd have to maintain an
auxiliary bit of code that can predict the result typmod. That's
a lot of code, and when you start considering user-defined functions
it gets worse. And all for what? Not to do anything useful, but only
to *eliminate* functionality. Perhaps char without typmod is
unnecessary (since it reduces to text), but numeric without typmod seems
highly useful to me.
Strikes me as a very large amount of work to go in the wrong
direction...
> A possible solution would be that data types can register a
> typmod-resolver function, which takes two typmods and returns the typmod
> to make both expressions union-compatible.
This only handles the UNION and CASE merge scenarios.
It'd probably be reasonable for UNION/CASE to copy the input typmod
if the alternatives all agree on the type and typmod. But solving
the general problem would be a lot of work of dubious value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-11-11 19:24:51 | Re: 7.2 doc comments |
Previous Message | Peter Eisentraut | 2001-11-11 15:39:30 | Re: Bug #513: union all changes char(3) column definition |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-11-11 16:57:07 | Re: [COMMITTERS] pgsql/src/backend/postmaster postmaster.c |
Previous Message | Peter Eisentraut | 2001-11-11 15:41:18 | Re: compiling libpq++ on Solaris with Sun SPRO6U2 (fixed |