Message-ID: <b3eb8019-c2db-557a-355b-7b02d6bc1cfb@postgresfriends.org>
Date: Sun, 25 Jun 2023 02:14:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: Add support for AT LOCAL
To: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Laurenz Albe <laurenz.albe@cybertec.at>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <20230612153707.sddawpenlaxo73aw@alvherre.pgsql>
Content-Language: en-US
From: Vik Fearing <vik@postgresfriends.org>
In-Reply-To: <20230612153707.sddawpenlaxo73aw@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/b3eb8019-c2db-557a-355b-7b02d6bc1cfb%40postgresfriends.org>
Precedence: bulk

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