Re: SQL:2011 application time

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

In response to

Browse pgsql-hackers by date

  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