From: | NikhilS <nikkhils(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: UPDATE using sub selects |
Date: | 2007-03-15 06:52:23 |
Message-ID: | d3c4af540703142352t2476efd8ybdc8c373ef672c78@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
>
> > The question is that since this enhances the UPDATE syntax, what changes
> and
> > where all they need to be made with respect to the documentation?
>
> Documentation is the very least of your worries. What exactly is your
> implementation plan? If this were a simple or narrow fix it would
> have been done already.
The implementation that I have planned is pretty similar to the way "INSERT
INTO ... SELECT" has been implemented.
Along with the grammar changes in gram.y, the changes are localized in the
transformUpdateStmt code path. The SELECT clause ends up becoming a subquery
to the update query with the target column expressions transformed properly
to include the subquery expressions. Does this sound ok?
I have tried some update-subselect variations and they seem to work. For
example the case in the src/test/regress/sql/update.sql, which used to fail
till now, seems to work:
UPDATE update_test SET (a,b) = (select a,b FROM update_test where c = 'foo')
WHERE a = 10;
Will try testing out some other variations too.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2007-03-15 08:11:52 | SoC ECPG Enhancements |
Previous Message | Tom Lane | 2007-03-15 06:32:55 | Re: UPDATE using sub selects |