Re: Cross-type index comparison support in contrib/btree_gin
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2025-02-07T22:41:32Z
Lists: pgsql-hackers
Attachments
- v2-0001-Break-out-xxx2yyy_opt_overflow-APIs-for-more-date.patch (text/x-diff) patch v2-0001
- v2-0002-Preliminary-refactoring.patch (text/x-diff) patch v2-0002
- v2-0003-Add-cross-type-comparisons-for-integer-types.patch (text/x-diff) patch v2-0003
- v2-0004-Add-cross-type-comparisons-for-float-types.patch (text/x-diff) patch v2-0004
- v2-0005-Add-cross-type-comparisons-for-string-types.patch (text/x-diff) patch v2-0005
- v2-0006-Add-cross-type-comparisons-for-datetime-types.patch (text/x-diff) patch v2-0006
I wrote: > I forgot to mention a couple of questions for review: > Should we adjust the documentation of comparePartial() to promise > explicitly that partial_key is the same datum returned by extractQuery? > By my reading, it kind of implies that, but it's not quite black and > white. > In the 0005 patch, I relied on date2timestamp_opt_overflow and > its siblings where available. But some of the conversions such > as timestamptz-to-timestamp don't have one of those, so I was > forced to copy-and-paste some fairly low-level code. Would it > make sense to refactor the related core routines to expose > xxx2yyy_opt_overflow interfaces, extending what 5bc450629 and > 52ad1e659 did? After further review it seems like both of those things would be improvements, so here's a v2 that does it like that. This also adds a PG_USED_FOR_ASSERTS_ONLY marker whose lack was pointed out by the cfbot; no other meaningful changes. regards, tom lane
Commits
-
Add more cross-type comparisons to contrib/btree_gin.
- fc896821c444 19 (unreleased) landed
-
Add cross-type comparisons to contrib/btree_gin.
- e2b64fcef35f 19 (unreleased) landed
-
Break out xxx2yyy_opt_overflow APIs for more datetime conversions.
- 0059bbe1ecaa 19 (unreleased) landed