From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Glenn Maynard <glenn(at)zewt(dot)org> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Bit by "commands ignored until end of transaction block" again |
Date: | 2009-07-23 10:55:16 |
Message-ID: | 20090723105516.GJ23840@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
* Glenn Maynard (glenn(at)zewt(dot)org) wrote:
> > The ORM can't control transactions, can't call functions or can't set
> > savepoints?
>
> It can't write the necessary SQL to say "insert this unless it already
> exists", namely:
If it can't cleanly handle failure cases like this one, then I think
your issue is with your ORM and not with PG. An INSERT failing on a
uniqueness violation is actually a rather big deal in a relational
database and not erroring on it goes quite against data integrity
considerations.
If your ORM could call a function instead, you could handle the insert
and error-check in the function, to make up for the lack of intelligence
in the ORM. Another option would be to have a 'fake' table, which has
no rows in it and just has an 'ON INSERT' trigger that calls a function
to handle this. That could also be a view with a do-instead rule, if
the ORM has to query the same table.
I would think the time would better be spent fixing the ORM though.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2009-07-23 14:20:03 | Re: Bit by "commands ignored until end of transaction block" again |
Previous Message | bartjoosen | 2009-07-23 09:59:05 | using count in other column |