On Sat, Nov 13, 2021 at 11:47 AM Ilya Anfimov wrote:
> Currently for glibc the version looks like glibc version at
> initdb, and that doesn't seem very reliable, but that could be a
> different task (to find LC_COLLATE file and put hash of the
> usuable data into version string, for
On Thu, Nov 11, 2021 at 09:52:52AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > I'm not really convinced that ICU is better, either. I think it's more
> > that it isn't used as much.
>
> Well, at least ICU has a notion of attaching versions to collations.
> How mindful they are of bumping
On Fri, Nov 12, 2021 at 8:42 AM Peter Eisentraut
wrote:
> There are standards for sort order, and the major hiccups we had in the
> past were mostly moving from older versions of those standards to newer
> versions. So at some point this should stabilize.
Only if they don't keep making new
On 11.11.21 18:32, Robert Haas wrote:
I agree with Tom that it sounds like a lot of work. And to be honest
it's work that I don't really feel very excited about. It would be
necessary to understand not only the bona fide sorting rules of every
human language out there, which might actually be
On Fri, Nov 12, 2021 at 12:09 PM Robert Haas wrote:
> On Thu, Nov 11, 2021 at 5:04 PM Isaac Morland wrote:
> > Wouldn't an existing index only have characters that were already part of
> > the collation? Attempting to use one not covered by the collation I would
> > have expected to cause an
On Thu, Nov 11, 2021 at 5:04 PM Isaac Morland wrote:
> Wouldn't an existing index only have characters that were already part of the
> collation? Attempting to use one not covered by the collation I would have
> expected to cause an error at insert time. But definitely I agree I wouldn't
>
On Thu, 11 Nov 2021 at 16:08, Robert Haas wrote:
> On Thu, Nov 11, 2021 at 3:45 PM Isaac Morland
> wrote:
> > There is however one kind of change at least that I think can be made
> safely: adding a new character in between existing characters. That
> shouldn't affect any existing indexes.
>
>
On Thu, Nov 11, 2021 at 3:45 PM Isaac Morland wrote:
> There is however one kind of change at least that I think can be made safely:
> adding a new character in between existing characters. That shouldn't affect
> any existing indexes.
Only if you can guarantee that said character is not
On Thu, 11 Nov 2021 at 14:42, Robert Haas wrote:
> diacritical marks. I know I've seen collation changes on Macs that
> changed the order in which en_US.UTF8 strings sorted. But it wasn't
> that the rules about English sorting have actually changed. It was
> that somebody somewhere decided that
On Thu, Nov 11, 2021 at 2:23 PM Tom Lane wrote:
> Robert Haas writes:
> > ... but we want
> > collation definitions that *actually don't change*.
>
> Um ... how would that work? Unicode is a moving target. Even without
> their continual addition of stuff, I'm not convinced that social rules
>
Robert Haas writes:
> ... but we want
> collation definitions that *actually don't change*.
Um ... how would that work? Unicode is a moving target. Even without
their continual addition of stuff, I'm not convinced that social rules
about how to sort are engraved on stone tablets. The need for
"Daniel Westermann (DWE)" writes:
> On Thu, 2021-11-11 at 09:52 -0500, Tom Lane wrote:
>> tzdb has an additional problem, which is that not updating is not an
>> option: if you're affected by a DST law change, you want that update,
>> and you frequently need it yesterday. We're definitely not
On Thu, Nov 11, 2021 at 1:38 PM Tom Lane wrote:
> Even if you were excited about it, would maintaining such data be
> a good use of project resources? It's not like we lack other things
> we ought to be doing. I agree that the lack of reliable versioning
> info is a problem, but I can't see
>Laurenz Albe writes:
>> On Thu, 2021-11-11 at 09:52 -0500, Tom Lane wrote:
>>> Yup. If we had reliable ways to detect changes in this sort of
>>> environment-supplied data, maybe we could do something about it
>>> (a la the work that's been happening on attaching collation versions
>>> to
Robert Haas writes:
> I agree with Tom that it sounds like a lot of work. And to be honest
> it's work that I don't really feel very excited about.
Even if you were excited about it, would maintaining such data be
a good use of project resources? It's not like we lack other things
we ought to
On Thu, Nov 11, 2021 at 11:16 AM Laurenz Albe wrote:
> Nobody will want to hear that, but the only really good solution would
> be for PostgreSQL to have its own built-in collations.
+1.
I agree with Tom that it sounds like a lot of work. And to be honest
it's work that I don't really feel very
Laurenz Albe writes:
> On Thu, 2021-11-11 at 09:52 -0500, Tom Lane wrote:
>> Yup. If we had reliable ways to detect changes in this sort of
>> environment-supplied data, maybe we could do something about it
>> (a la the work that's been happening on attaching collation versions
>> to indexes).
On Thu, 2021-11-11 at 09:52 -0500, Tom Lane wrote:
> Robert Haas writes:
> > I'm not really convinced that ICU is better, either. I think it's more
> > that it isn't used as much.
>
> Well, at least ICU has a notion of attaching versions to collations.
> How mindful they are of bumping the
Robert Haas writes:
> I'm not really convinced that ICU is better, either. I think it's more
> that it isn't used as much.
Well, at least ICU has a notion of attaching versions to collations.
How mindful they are of bumping the version number when necessary
remains to be seen. But the POSIX
On Wed, Nov 10, 2021 at 6:03 PM Tom Lane wrote:
> For comparison's sake, glibc have modified their
> collation rules significantly (enough for us to hear complaints about
> it) at least twice in the past decade. That's considerably *more*
> frequent than DST law changes where I live.
Yes. It
> Yeah, it's not clear that forbidding this would make anyone's life any
> better. If you want an index on the UTC equivalent of a local time,
> you're going to have to find a way to cope with potential mapping
> changes. But refusing to let you use a generated column doesn't
> seem to help
Shay Rojansky writes:
>> Yeah, we generally don't take such hazards into account. The poster
>> child here is that if we were strict about this, text comparisons
>> couldn't be immutable, because the underlying collation rules can
>> (and do) change from time to time. That's obviously
> > It seems that PostgreSQL 14 allows using the AT TIME ZONE operator
within
> > generated column definitions; according to the docs, that means the
> > operator is considered immutable. However, unless I'm mistaken, the
result
> > of AT TIME ZONE depends on the time zone database, which is
Shay Rojansky writes:
> It seems that PostgreSQL 14 allows using the AT TIME ZONE operator within
> generated column definitions; according to the docs, that means the
> operator is considered immutable. However, unless I'm mistaken, the result
> of AT TIME ZONE depends on the time zone database,
Greetings hackers.
It seems that PostgreSQL 14 allows using the AT TIME ZONE operator within
generated column definitions; according to the docs, that means the
operator is considered immutable. However, unless I'm mistaken, the result
of AT TIME ZONE depends on the time zone database, which is
25 matches
Mail list logo
