Re: MERGE Support (SQL2003) - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: MERGE Support (SQL2003) |
Date | |
Msg-id | 20040415191150.GY7060@ns.snowman.net Whole thread Raw |
In response to | Re: MERGE Support (SQL2003) (Greg Stark <gsstark@mit.edu>) |
List | pgsql-hackers |
* Greg Stark (gsstark@mit.edu) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > > c) > > merge into T1 USING VALUES (1,2,4); > > I'm not happy with the implied use of the primary key. a) some tables can have > two effective primary keys, even if only one is explicitly declared as such. > and b) some update/inserts are done with where clauses that aren't primary > keys at all. and c) you might want to update any record for a date within the > last week but if you insert then insert with the current date. Certainly using the primary key won't work for all cases, it's not meant to. The intent was to allow a simpler syntax for what is likely to be a common case. Also, I didn't want to diviate too much from the specification by changing intent or ordering of clauses. The cases you describe above would look something like: merge into T1 USING VALUES (1,2,4) ON (a=1,b=2); > I see this as vaguely analogous to the NATURAL JOIN/ON/USING where I feel > using NATURAL JOIN to work automatically is somewhat risky and hides too much > of whats happening. I would think the key columns should always be explicitly > named in permanent code. Explicitly naming what columns are key vs. what columns are data and should be replaced is possible with the formal syntax from the specification, which I certainly think should be supported in addition to anything else. I'd really like to be able to use a more simplified syntax for the common/simple case though. > Similarly vaguely analogous to the ON/USING distinction I would think you > would want a form of this where the key columns simply named. And one where > the where clauses could be enumerated. That's possible but as I mentioned I didn't want to move too far away from the specification either.. > So I would suggest doing something like this which is basically exactly > equivalent to an INSERT statement except with an added ON/USING clause exactly > like the syntax in SELECT. > > MERGE INTO t1 USING (col1,col2) VALUES (1,2,4) I don't have a problem with this from a verbosity standpoint but I am concerned that it deviates from the specification by what's expected in the 'USING' clause. The USING clause is intended to be the source not the match/search clause (that's the 'ON' clause which follows the USING clause). > Or explicitly naming columns (which I argue should be done on inserts): > > MERGE INTO t1 USING (col1,col2) (col1,col2,col3) VALUES (1,2,4) Same issue as above for this. > MERGE INTO t2 ON (col1='1',col2='2' OR col2='3') > (col1,col2,col3) > VALUES > (1,2,4) This is closer to how the specification lays out the clauses but starts to get more verbose and doesn't include the 'USING' keyword the specification lays out for defining the source. Perhaps something like this: merge into t1 using (select 1 as col1,2 as col2,3 as col3) ON a=col1 and b=col2; This follows the specification except the 'WHEN' clauses are implied here and having a select inside the using clause. It's also rather length for the simple case in my view. This would be better, but deviates more: merge into T1 using col1=1,col2=2,col3=3 ON a=col1 and b=col2; Or merge into T1 using (col1,col2,col3) (1,2,3) ON a=col1 and b=col2; Thanks, Stephen
pgsql-hackers by date: