Horton

Re: Add support for AT LOCAL

Vik Fearing <vik@postgresfriends.org>

View thread View on postgr.es
From: Vik Fearing <vik@postgresfriends.org>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>, Laurenz Albe <laurenz.albe@cybertec.at>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-06-25T00:14:52Z
Lists: pgsql-hackers 
On 6/12/23 17:37, Alvaro Herrera wrote:
> On 2023-Jun-06, Laurenz Albe wrote:
> 
>> At a quick glance, it looks like you resolve "timezone" at the time
>> the query is parsed.  Shouldn't the resolution happen at query
>> execution time?
> 
> Sounds like it -- consider the case where the timestamp value is a
> partition key and one of the partition boundaries falls in between two
> timezone offsets for some particular ts value; then you use a prepared
> query to read from a view defined with AT LOCAL.  Partition pruning
> would need to compute partitions to read from at runtime, not plan time.


Can you show me an example of that happening with my patch?
-- 
Vik Fearing

Commits

  1. Dodge a compiler bug affecting timetz_zone/timetz_izone.

  2. Back-patch test cases for timetz_zone/timetz_izone.

  3. Add regression test coverage for timetz_izone().

  4. Add support for AT LOCAL

  5. doc: Mention timezone(zone, time) in section for AT TIME ZONE

  6. Use HASH_BLOBS for xidhash.