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

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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