| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-20 10:21:41 |
| Message-ID: | 1df262d4-003b-4e4c-ab9e-aca4e26ec16d@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 14.11.23 17:15, Tom Lane wrote:
> I don't love the patch details though. It seems entirely wrong to check
> this before we check the opclass match.
Not sure why? The order doesn't seem to matter?
> 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.
I see. That means we shouldn't raise an error on a mismatch but just do
if (key->partcollation[i] != collationIds[j])
continue;
and then let the existing error under if (!found) complain.
I suppose we could move that into the
if (get_opclass_opfamily_and_input_type(...))
block. I'm not sure I see the difference.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2023-11-20 10:35:15 | Re: Use of backup_label not noted in log |
| Previous Message | Laurenz Albe | 2023-11-20 10:18:06 | Re: Perhaps a possible new feature to a future PostgreSQL release |