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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
