From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
---|---|
To: | mlw <markw(at)mohawksoft(dot)com> |
Cc: | Jan Wieck <JanWieck(at)yahoo(dot)com>, Dale Johnson <djohnson(at)mi(dot)ab(dot)ca>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: REPLACE INTO table a la mySQL |
Date: | 2001-06-11 23:11:58 |
Message-ID: | Pine.BSO.4.10.10106111910210.9902-100000@spider.pilosoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 11 Jun 2001, mlw wrote:
> > Adding another trigger event type will break every existing
> > DB schema that relies on custom triggers to ensure logical
> > data integrity. Thus it is unacceptable as solution to
> > support a non-standard feature - period.
> >
> > The question "does this row exist" can only be answered by
> > looking at the primary key. Now BEFORE triggers are allowed
> > to alter the key attributes, so the final primary key isn't
> > known before they are executed.
> >
> > Thus the DELETE then INSERT semantic might be the only way.
> > Pretty havy restriction, making the entire REPLACE INTO
> > somewhat useless IMHO.
>
> The only issue I have with your conclusion about DB schema is that
> REPLACE is not part of standard SQL, so we do not need be too
> concerned. Just give them a REPLACE trigger and be done with it. If
> that isn't good enough, in the FAQ, say that the standard way is
> insert or update.
I am not sure I like this: it is possible that someone's security is based
on triggers, and adding replace as a trigger will let them get around
it...Possibly this could be controlled by serverwide option
'enable_replace_into' or something like that for people with such setup..?
-alex
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-06-11 23:28:37 | global.bki vs template1.bki init files |
Previous Message | Bruce Momjian | 2001-06-11 22:52:52 | Re: Australian timezone configure option |