Feedback-ID: ie0a040ee:Fastmail
Message-ID: <f22f65c8-865d-4753-94cc-3b954c29ad5c@eisentraut.org>
Date: Tue, 19 Mar 2024 12:02:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: SQL:2011 application time
Content-Language: en-US
To: Paul A Jungwirth <pj@illuminatedcomputing.com>,
 jian he <jian.universality@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com>
 <71b45adb-b496-4e58-b134-0a091014e63f@illuminatedcomputing.com>
 <7be8724a-5c25-46d7-8325-1bd8be6fa523@eisentraut.org>
 <CACJufxHVg65raNhG2zBwXgjrD6jqace4NZbePyMhP8-_Q=iT8w@mail.gmail.com>
 <0af6a323-f026-4cd9-adf1-941038cd00de@illuminatedcomputing.com>
 <88518c81-dcdc-4c5b-9200-146b74a520ab@eisentraut.org>
 <113f5e25-4455-4bdb-98ec-56275705cc4e@illuminatedcomputing.com>
 <7bd1c8f9-a91a-41a3-990e-0f796ba692ec@eisentraut.org>
 <d1a793bd-d1f1-46d7-90b6-8b89b6feb1cc@illuminatedcomputing.com>
 <6c3edb2c-bc45-4f19-babd-8f4edf39b384@illuminatedcomputing.com>
 <41b57948-f4d3-455f-8880-e0ce7e61ffc1@illuminatedcomputing.com>
 <0d977c63-f4a6-43ba-aad0-35c06c55df11@eisentraut.org>
 <CACJufxFFeUHoBomd2856amDBccNVQZzA=Jrk1_FDdvSZ1+X7og@mail.gmail.com>
 <CACJufxEACgLY7YUvzo8j=iOB-z6-1QHAvMr8cUHRP7b_F_vo3A@mail.gmail.com>
 <CA+renyXHFFyq1n2+4cwcFoLXqzUhb6u6WCL6wjk8ZjP9WxTExw@mail.gmail.com>
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CA+renyXHFFyq1n2+4cwcFoLXqzUhb6u6WCL6wjk8ZjP9WxTExw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/f22f65c8-865d-4753-94cc-3b954c29ad5c%40eisentraut.org>
Precedence: bulk

On 16.03.24 22:37, Paul A Jungwirth wrote:
> Here is a new patch series addressing the last few feedback emails
> from Peter & Jian He. It mostly focuses on the FKs patch, trying to
> get it really ready to commit,

I have committed the test changes (range and date format etc.).

The FOREIGN KEY patch looks okay to me now.  Maybe check if any of the 
subsequent comments from jian should be applied.

>>   > I'm not sure how else to do it. The issue is that `range_agg` returns
>>   > a multirange, so the result
>>   > type doesn't match the inputs. But other types will likely have the
>>   > same problem: to combine boxes
>>   > you may need a multibox. The combine mdranges you may need a
>>   > multimdrange.
>>
>> Can we just hardcode the use of range_agg for this release?  Might be
>> easier.  I don't see all this generality being useful in the near future.
> 
> Okay, I've hard-coded range_agg in the main patch and separated the
> support for multirange/etc in the next two patches. But there isn't
> much code there (mostly tests and docs). Since we can't hard-code the
> *operators*, most of the infrastructure is already there not to
> hard-code the aggregate function. Supporting multiranges is already a
> nice improvement. E.g. it should cut down on disk usage when a record
> gets updated frequently. Supporting arbitrary types also seems very
> powerful, and we already do that for PKs.

I think we could also handle multiranges in a hardcoded way?  Ranges and 
multiranges are hardcoded concepts anyway.  It's just when we move to 
arbitrary types supporting containment, then it gets a bit more complicated.

What would a patch that adds just multiranges on the FK side, but 
without the full pluggable gist support, look like?

> I don't see any drawbacks from supporting inferred REFERENCES with
> temporal tables, so my vote is to break from the standard here, and
> *not* apply that follow-up patch. Should I add some docs about that?
> Also skipping the patch will cause some annoying merge conflicts, so
> let me know if that's what you choose and I'll handle them right away.

I agree we can allow this.