On Sat, Nov 4, 2017 at 6:41 PM, Marc-Olaf Jaschke wrote:
> Perhaps I misunderstand the discussion but would "INSERT .. ON CONFLICT DO
> SELECT [FOR ..]" not provide a solution for the following use case?
>
> [ .. ]
>
> That works. But it is a bit inconvenient to write the pseudo update clause.
>
to destroy, and everything appears to
be working correctly.
Regards,
Marko Tiikkaja
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
eds to unconditionally clear the
surround SPI context, or why it assumes it's a good idea.
Regards,
Marko Tiikkaja
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
o correctly
clean up after an exception? The attached code tries to imitate what
the PLs are doing, but it's not working. :-(
Regards,
Marko Tiikkaja
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "postgres.h"
#include "
gt; this happens some of the underlying rule's update statements were in
>> fact processed, so the refreshed row in the view appears to have an
>> non-atomic update even though the client rolls back the transaction.
>>
>> The following email was my first discovery
