Re: Materialized views WIP patch
Peter Eisentraut <peter_e@gmx.net>
From: Peter Eisentraut <peter_e@gmx.net>
To: Kevin Grittner <kgrittn@mail.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2012-11-27T00:35:03Z
Lists: pgsql-hackers
On Mon, 2012-11-26 at 09:46 -0500, Peter Eisentraut wrote: > On 11/14/12 9:28 PM, Kevin Grittner wrote: > > 17. Since the data viewed in an MV is not up-to-date with the latest > > committed transaction, > > So, the way I understand it, in Oracle terms, this feature is a > "snapshot", not a materialized view. Maybe that's what it should be > called then. OK, I take everything back and claim the opposite. In current Oracle, SNAPSHOT is an obsolete alias for MATERIALIZED VIEW. Materialized views have the option of REFRESH ON DEMAND and REFRESH ON COMMIT, with the former being the default. So it seems that the syntax of what you are proposing is in line with Oracle. I'm not fond of overloading LOAD as the refresh command. Maybe you could go the Oracle route here as well and use a stored procedure. That would also allow things like SELECT pg_refresh_mv(oid) FROM ... more easily.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Preserve intermediate .c files in coverage mode
- 4af3dda13601 9.3.0 cited