Re: \dO versus collations for other encodings

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: \dO versus collations for other encodings
Date: 2011-04-09 21:22:23
Message-ID: 1302384143.9864.5.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On fre, 2011-04-08 at 20:14 -0400, Tom Lane wrote:
> Given that this display doesn't include any encoding column, I'm
> thinking that the intention was to show only relevant collation
> entries.
> Which we could do by adding a WHERE clause about the encoding.
> If the intention was to not restrict that way, don't we need an
> encoding
> column? (But I'm not actually sure how we could make that work
> unsurprisingly without changes in CollationGetCollid, which would
> likely
> break other things, so I don't really want to hear suggestions that we
> should do it the other way ...)

The fix you pushed looks OK.

The whole way of dealing with the wrong encodings has been schizophrenic
throughout the development of this feature. One idea was that at some
point we could add support for creating collations in the wrong encoding
in template databases, if that turns out to be something that is
requested. You can, of course, do that manually already.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-04-09 21:33:30 Re: Open issues for collations
Previous Message Brendan Jurd 2011-04-09 19:18:30 Re: Bug in pg_hba.conf or pg_basebackup concerning replication connections