| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [18] Policy on IMMUTABLE functions and Unicode updates |
| Date: | 2024-07-23 19:26:55 |
| Message-ID: | 1078884.1721762815@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Also, Noah has pointed out that C.UTF-8 introduces some
> forward-compatibility hazards of its own, at least with respect to
> ctype semantics. I don't have a clear view of what ought to be done
> about that, but if we just replace a dependency on an unstable set of
> libc definitions with a dependency on an equally unstable set of
> PostgreSQL definitions, we're not really winning.
No, I think we *are* winning, because the updates are not "equally
unstable": with pg_c_utf8, we control when changes happen. We can
align them with major releases and release-note the differences.
With libc-based collations, we have zero control and not much
notification.
> Do we need to version the new ctype provider?
It would be a version for the underlying Unicode definitions,
not the provider as such, but perhaps yes. I don't know to what
extent doing so would satisfy Noah's concern; but if it would do
so I'd be happy with that answer.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-07-23 19:39:40 | Re: Useless toast |
| Previous Message | Robert Haas | 2024-07-23 18:40:27 | Re: [18] Policy on IMMUTABLE functions and Unicode updates |