| 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-02-18 16:45:39 |
| Message-ID: | 6650.1298047539@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tor, 2011-02-17 at 17:50 -0500, Tom Lane wrote:
>> Is it time for a direct UPDATE on the pg_type row? If so, to what? I see
>> pg_type.typcollation is supposed to be an OID, so how the heck does
>> one map a bool CREATE TYPE parameter into the catalog entry?
> It's 100, which is the OID of "default" in pg_collation. The value may
> be different for domains. (Earlier versions of the feature had a
> boolean column and a separate collation column for domains, but somehow
> it turned out to be quite redundant.)
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. 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.
In short: I think this feature is quite a few bricks shy of a load yet,
and there's no point in my kluging something in citext until it settles
down more.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-02-18 16:50:42 | Re: Re: [COMMITTERS] pgsql: Make a hard state change from catchup to streaming mode. |
| Previous Message | Kevin Grittner | 2011-02-18 16:14:56 | Re: Students enrollment |