Re: ALTER TABLE INHERIT vs collations

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE INHERIT vs collations
Date: 2011-04-17 01:19:54
Message-ID: BANLkTikBnRBKFKcmD3RpEzhTG+Y08LGVZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 16, 2011 at 6:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Right at the moment, ALTER INHERIT doesn't verify that collations match
> in a proposed inheritance child.  So you can do this:
>
> regression=# create table foo (f1 text collate "C");
> CREATE TABLE
> regression=# create table bar (f1 text collate "POSIX");
> CREATE TABLE
> regression=# alter table bar inherit foo;
> ALTER TABLE
>
> but then the planner whines about it:
>
> regression=# select * from foo;
> ERROR:  attribute "f1" of relation "bar" does not match parent's collation
>
> 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?

We seem to generally be treating collations as type information, so
that seems to argue that we ought to force it to match here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-04-17 01:23:13 Re: Formatting Curmudgeons WAS: MMAP Buffers
Previous Message Christopher Browne 2011-04-17 01:12:25 Re: Formatting Curmudgeons WAS: MMAP Buffers