| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: should check collations when creating partitioned index |
| Date: | 2023-11-14 16:15:10 |
| Message-ID: | 2491496.1699978510@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> On 13.11.23 21:04, Laurenz Albe wrote:
>> This will be backpatched, right? What if somebody already created an index like that?
>> Does this warrant an entry in the "however" for the release notes, or is the case
>> exotic enough that we can assume that nobody is affected?
> I think it's exotic enough that I wouldn't bother backpatching it. But
> I welcome input on this.
I think it should be back-patched.
I don't love the patch details though. It seems entirely wrong to check
this before we check the opclass match. Also, in at least some cases
the code presses on looking for another match if the current opclass
doesn't match; you've broken such cases.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2023-11-14 16:15:49 | Re: Why do indexes and sorts use the database collation? |
| Previous Message | Nathan Bossart | 2023-11-14 16:05:53 | Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro |