| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add support for AT LOCAL |
| Date: | 2023-06-12 15:37:07 |
| Message-ID: | 20230612153707.sddawpenlaxo73aw@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2023-06-12 15:43:28 | Re: Do we want a hashset type? |
| Previous Message | Tristan Partin | 2023-06-12 15:23:55 | Re: abi-compliance-checker |