Re: ALTER TABLE INHERIT vs collations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thom Brown <thom(at)linux(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE INHERIT vs collations
Date: 2011-04-16 23:40:57
Message-ID: 12373.1302997257@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thom Brown <thom(at)linux(dot)com> writes:
> On 16 April 2011 23:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Does anyone think it's not a bug that ALTER TABLE lets this through?
>> If so, what do you think the querying semantics ought to be?

> An argument to not treat it as a bug might be to suggest that the
> child table's column could inherit the parent table's column collation
> when the query targets the parent, but revert to its own otherwise.

That seems to me to be about on par with arguing that inheritance
shouldn't demand column type matching, but should coerce child columns
on-the-fly to their parent's type. Even if you don't think that's
horrid from a theoretical standpoint, there's a good practical reason
not to allow it: if it acts that way, then indexes on the child column
will silently not be usable for many kinds of query against the parent.
People will be tearing their hair out looking for the cause of their
performance problems ... and, no doubt, filing bugs against the planner
... when throwing an error would have helped them catch the mismatch.

I think there needs to be a pretty darn compelling use-case for such
mismatches before we should allow them. And I don't see one.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2011-04-16 23:45:18 Re: ALTER TABLE INHERIT vs collations
Previous Message Tom Lane 2011-04-16 23:35:45 Re: MMAP Buffers