Horton

Re: Add support for AT LOCAL

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Vik Fearing <vik@postgresfriends.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-06-12T15:37:07Z
Lists: pgsql-hackers 
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.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

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.