Re: AS OF queries

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

In response to

Responses

Browse pgsql-hackers by date

  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