From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER TYPE COLLATABLE? |
Date: | 2011-03-01 21:31:02 |
Message-ID: | 27152.1299015062@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On fre, 2011-02-18 at 11:45 -0500, Tom Lane wrote:
>> While testing a fix for this, I observe that pg_dump is entirely
>> broken on the subject, because it fails to dump anything at all about
>> the typcollation property when dumping a base type.
> This is now fixed.
>> I also rather wonder
>> exactly what pg_dump would dump to restore a value of
>> pg_type.typcollation that's not either 0 or 100.
> It does what pg_dump does with other unrecognized or invalid type
> attributes: it ignores them.
I can't say that this makes me think any better of the design here.
If a boolean true/false is a sufficient representation of a type's
collation property, why isn't the column in pg_type just a boolean?
If the idea of storing an OID is to allow reference to a choice of
collations, why are we painting ourselves into a corner by dumping
it as a boolean? ISTM there are exactly two sane choices here:
1. Change the pg_type column to a boolean.
2. Change the CREATE TYPE command's representation of the COLLATION
property to be the name of the referenced collation.
If there is a reason why the current design is actually correct,
please explain it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-01 21:38:26 | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |
Previous Message | Magnus Hagander | 2011-03-01 21:23:17 | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |