Re: Re: REPLACE INTO table a la mySQL
От | Alex Pilosov |
---|---|
Тема | Re: Re: REPLACE INTO table a la mySQL |
Дата | |
Msg-id | Pine.BSO.4.10.10106111910210.9902-100000@spider.pilosoft.com обсуждение исходный текст |
Ответ на | Re: Re: REPLACE INTO table a la mySQL (mlw <markw@mohawksoft.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: