Horton

Re: [HACKERS] MERGE SQL Statement for PG11

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Pavan Deolasee <pavan.deolasee@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-24T06:35:01Z
Lists: pgsql-hackers 
On Fri, Mar 23, 2018 at 11:15 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> I agree that this is very similar, as far as the RTEs go. What is
> dissimilar is the fact that there is hard-coded knowledge of both
> through parsing, planning, and execution. It's everything, taken
> together.
>
> ResultRelInfo has a ri_mergeTargetRTI field, which seems to be used
> instead of ri_RangeTableIndex in some contexts but not others. What
> might the interactions with something like GetInsertedColumns() and
> GetUpdatedColumns() be? Is that explained anywhere? In general, I
> think that there is potential for things to break in subtle ways.

I just realized that there were no tests added to privileges.sql. You
only have a small number of GRANT tests in merge.sql, for
relation-level privileges, not column-level privileges. IOW, this area
is totally untested.


-- 
Peter Geoghegan

Commits

  1. Add support for MERGE SQL command

  2. Avoid repeated name lookups during table and index DDL.

  3. Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.