Re: Collations and Replication; Next Steps

On 9/17/14 10:46 AM, Greg Stark wrote:
> You could have a problem if you have an expression index on (timestamp
> AT TIME ZONE '...'). I may have the expression slightly wrong but I
> believe it is posisble to write an immutable expression that depends
> on the tzdata data as long as it doesn't depend on not the user's
> current time zone (which would be stable but not immutable). The
> actual likelihood of that situation might be much lower and the
> ability to avoid it higher but in theory I think Peter's right that
> it's the same class of problem.

I was thinking of something like a text column with "natural" input of
time stamp information, and and index on that_column::timestamp.

> Generally speaking we try to protect against most environment
> dependencies that lead to corrupt databases by encoding them in the
> control file. Obviously we can't encode an entire collation in the
> controlfile though. We could conceivably have a corpus of
> representative strings that we sort and then checksum in the
> controlfile. It wouldn't be foolproof but if we collect interesting
> examples as we find them it might be a worthwhile safety check.

I think it could be useful in a number of situations if a type could
stick some arbitrary additional information into a new column in
pg_type, such as versions of libraries it depends on or storage format
versions.

Then again, collation isn't actually a property of any single type.