Andres Freund <and...@anarazel.de> writes:
> On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
>> I think that's fragile as can be.
> Hm. I think actually just forcing a collation would bring this on-par
> with name, right? We don't have any guarantees about the contents of
> e.g. pg_database.datname being meaningful in another database with a
> different encoding. In fact even the current database may have a name
> that's in a wrong encoding.
Oh, wait a minute. I just noticed that you have
pg_replication_origin_roname_index defined to use varchar_pattern_ops.
Now, this is mildly broken: it should be text_pattern_ops. But as far as
I can see offhand, that eliminates the collation dependency for the index.
The comparison rule is memcmp() which is not collation sensitive.
I'm inclined to think I should revert b82a7be603f1811a and instead make
the seclabel provider columns use text_pattern_ops. That would fix
their collation problem with less of a backwards compatibility hazard.
> I'm right now toying with the idea of defining 'varname' as a text
> equivalent that always has a C type collation, and no length
> limitation.
That doesn't really address the encoding problem, so I'm not sure it
advances the state of the art particularly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
