From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SQL:2011 application time |
Date: | 2023-10-13 00:48:28 |
Message-ID: | 8a47be1e-4d12-4eb8-b3d6-90371a715ebc@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/11/23 05:47, Paul Jungwirth wrote:
>> +SELECT pg_get_indexdef(conindid, 0, true) FROM pg_constraint WHERE
>> conname = 'temporal_rng_pk';
>> + pg_get_indexdef
>> +-------------------------------------------------------------------------------
>> + CREATE UNIQUE INDEX temporal_rng_pk ON temporal_rng USING gist (id,
>> valid_at)
>>
>> Shouldn't this somehow show the operator classes for the columns? We
>> are using different operator classes for the id and valid_at columns,
>> aren't we?
>
> We only print the operator classes if they are not the default, so they
> don't appear here.
>
> I do suspect something more is desirable though. For exclusion
> constraints we replace everything before the columns with just "EXCLUDE
> USING gist". I could embed WITHOUT OVERLAPS but it's not valid syntax in
> CREATE INDEX. Let me know if you have any ideas.
Why not? The standard does not mention indexes (although some
discussions last week might change that) so we can change the syntax for
it as we wish. Doing so would also allow us to use ALTER TABLE ...
USING INDEX for such things.
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2023-10-13 01:07:25 | Re: Tab completion for AT TIME ZONE |
Previous Message | Michael Paquier | 2023-10-13 00:40:04 | Re: Some performance degradation in REL_16 vs REL_15 |