Re: UPSERT wiki page, and SQL MERGE syntax

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: UPSERT wiki page, and SQL MERGE syntax
Дата
Msg-id CABRT9RBi6ROccM4iN83HvWJVoHFdHu0XiR6u0sOgRhur2wGPZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UPSERT wiki page, and SQL MERGE syntax  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: UPSERT wiki page, and SQL MERGE syntax
Список pgsql-hackers
On Thu, Oct 9, 2014 at 1:51 AM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
>> Although the last go-around does suggest that there is at least one
>> point of difference on the semantics.  You seem to want to fire the
>> BEFORE INSERT triggers before determining whether this will be an
>> INSERT or an UPDATE.  That seems like a bad idea to me

Indeed, the current behavior breaks even the canonical "keep track of
how many posts are in a thread" trigger example because INSERT
triggers are fired for an effective row UPDATE. I can't see how that's
acceptable.

> Well, it isn't that I'm doing it because I think that it is a great
> idea, with everything to recommend it. It's more like I don't see any
> practical alternative.

I proposed an alternative that avoids this surprise and might allow
some other benefits. Can you please look into that? Even a "clarify
this", "this couldn't possibly work" or "you're not a major
contributor so your arguments are invalid" response. ;)

I admit I initially misunderstood some details about the current
behavior. I can dig into the code and write a clearer and/or more
detailed spec if I had even *some* feedback.

Regards,
Marti



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add CREATE support to event triggers
Следующее
От: Ian Barwick
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL