From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AS OF queries |
Date: | 2018-01-02 18:12:13 |
Message-ID: | bb5b5dee-bdd3-06cd-c08a-6d3ee1551487@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/29/17 06:28, Konstantin Knizhnik wrote:
>> Can there be apparent RI
>> violations?
> Right now AS OF is used only in selects, not in update statements. So I
> do not understand how integrity constraints can be violated.
I mean, if you join tables connected by a foreign key, you can expect a
certain shape of result, for example at least one match per PK row. But
if you select from each table "as of" a different timestamp, then that
won't hold. That could also throw off any optimizations we might come
up with in that area, such as cross-table statistics. Not saying it
can't or shouldn't be done, but there might be some questions.
>> What happens if no old data for the
>> selected AS OF is available?
> It will just return the version closest to the specified timestamp.
That seems strange. Shouldn't that be an error?
>> How does this interact with catalog
>> changes, such as changes to row-level security settings? (Do we apply
>> the current or the past settings?)
> Catalog changes are not currently supported.
> And I do not have good understanding how to support it if query involves
> two different timeslice with different versions of the table.
> Too much places in parser/optimizer have to be change to support such
> "historical collisions".
Right, it's probably very hard to do. But I think it somehow should be
recognized that catalog changes took place between the selected
timestamp(s) and now and an error or notice should be produced.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-01-02 18:25:44 | Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME |
Previous Message | Marco Nenciarini | 2018-01-02 18:11:11 | Re: [PATCH] Logical decoding of TRUNCATE |