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/