Partitioned table and trigger/insert result horribleness

Поиск
Список
Период
Сортировка
От Henry
Тема Partitioned table and trigger/insert result horribleness
Дата
Msg-id 20090406095751.18134039e8orzsis@zenmail.co.za
обсуждение исходный текст
Ответы Re: Partitioned table and trigger/insert result horribleness  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-general
Greetings,

I recently successfully partitioned a 100+GB table into many smaller
ones for improved select performance, etc.  This works extremely well,
I must say.  SELECTs, UPDATEs and DELETEs are handled automatically by
Pg, my trigger takes care of distributing INSERTs, etc.

Only problem is (and to my horror), an INSERT always returns 0
(whereas UPDATE/DELETE return 1) - which is *technically* the correct
answer, since that's the return value from the trigger.  However, this
is counter-intuitive since an insert into a parent table which is
partitioned should return a result similar to what an update/delete
would.  argh!

This presents a terrible problem with existing code which diligently
checks the return values from SQL statements.

Is this weirdness scheduled to be addressed in 8.4, or is there some
other hack I can try (without changing all SQL), or is the *only*
solution to mess with existing (working) front-end code to work around
this issue?

Right now, the untenable situation is to simply ignore the return
codes and act like all is well in la-la land.

Comments, admonishments, hope for the future, all welcome.

Cheers!
Henry

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

Предыдущее
От: raf
Дата:
Сообщение: Re: 8.3.5 problem with plpgsql selecting into an array variable
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: Postgres Security Checklist