Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 2C1436325CC for ; Thu, 23 Jul 2009 07:56:47 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 83166-02 for ; Thu, 23 Jul 2009 07:56:30 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from tamriel.snowman.net (tamriel.snowman.net [72.66.115.51]) by mail.postgresql.org (Postfix) with ESMTP id A0C20634414 for ; Thu, 23 Jul 2009 07:55:18 -0300 (ADT) Received: by tamriel.snowman.net (Postfix, from userid 1000) id C41FF22975; Thu, 23 Jul 2009 06:55:16 -0400 (EDT) Date: Thu, 23 Jul 2009 06:55:16 -0400 From: Stephen Frost To: Glenn Maynard Cc: Richard Huxton , pgsql-sql@postgresql.org Subject: Re: Bit by "commands ignored until end of transaction block" again Message-ID: <20090723105516.GJ23840@tamriel.snowman.net> References: <4A67F5B6.4080409@archonet.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jIYo0VRlfdMI9fLa" Content-Disposition: inline In-Reply-To: X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.6.26-1-amd64 (x86_64) X-Uptime: 06:50:16 up 42 days, 8:17, 13 users, load average: 0.22, 0.07, 0.03 User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.069 tagged_above=-10 required=5 tests=AWL=0.069 X-Spam-Level: X-Archive-Number: 200907/118 X-Sequence-Number: 32859 --jIYo0VRlfdMI9fLa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Glenn Maynard (glenn@zewt.org) wrote: > > The ORM can't control transactions, can't call functions or can't set > > savepoints? >=20 > 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 --jIYo0VRlfdMI9fLa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpoQZQACgkQrzgMPqB3kigL7wCeNRI5ot+xp5hxnQlZNtUVn1mn +gMAoIgfTp45dtfNo1UthwvDgvzC2UAu =pkgx -----END PGP SIGNATURE----- --jIYo0VRlfdMI9fLa--