I wrote:
> On balance I think we ought to switch to set-all-the-columns, though
> only in 9.3+ --- a back-patched behavioral change doesn't seem like a
> good idea.
And here is a draft patch for that. I was interested to find that the
documentation already claims that all columns are set in the r
I wrote:
> Anybody have DB2, or something else that might be thought to be pretty
> close to spec-compliant?
Remarkably enough, the DB2 10.1 manuals at www.ibm.com say that it
doesn't support ON UPDATE SET NULL or ON UPDATE SET DEFAULT. I'm
disappointed in them :-(. But anyway it seems that we'l
2012/6/16 Tom Lane :
> I wrote:
>> Have the SQL committee simply failed to notice that in
>> whacking this text around they changed the meaning? Which behavior is
>> actually implemented by other RDBMSes?
>
> If anyone is up for actually trying this, here is a script to test the
> behavior in ques
On 16 June 2012 21:18, Tom Lane wrote:
> Anybody have DB2, or something else that might be thought to be pretty
> close to spec-compliant?
>
I have an Oracle DB, but they're not exactly known for spec
compliance. In fact they dodge this entire issue by not supporting ON
UPDATE actions at all :-)
I wrote:
> Have the SQL committee simply failed to notice that in
> whacking this text around they changed the meaning? Which behavior is
> actually implemented by other RDBMSes?
If anyone is up for actually trying this, here is a script to test the
behavior in question:
create table pp (f1 int,
While looking at Vik Reykja's pending patch to improve the FK triggers
by skipping processing when a NULL column didn't change, I started to
wonder whether that really had no user-visible semantic effect.
In particular, in ON UPDATE SET NULL/SET DEFAULT cases, it seemed like
this could change the s
