2013/11/20 Tom Lane :
> Robert Haas writes:
>> On Mon, Nov 18, 2013 at 9:39 AM, Ian Lawrence Barwick
>> wrote:
>>> I'd expect this to lead to a failed transaction block,
>>> or at least some sort of notice that the transaction itself
>>> has been rolled back.
>
>> Ending up in a failed transacti
Robert Haas writes:
> On Mon, Nov 18, 2013 at 9:39 AM, Ian Lawrence Barwick
> wrote:
>> I'd expect this to lead to a failed transaction block,
>> or at least some sort of notice that the transaction itself
>> has been rolled back.
> Ending up in a failed transaction block would be wrong. If th
On 11/19/2013 10:58 AM, Robert Haas wrote:
On Mon, Nov 18, 2013 at 9:39 AM, Ian Lawrence Barwick wrote:
postgres=# BEGIN ;
BEGIN
postgres=*# INSERT INTO foo (id) VALUES (1);
INSERT 0 1
postgres=*# COMMIT ;
NOTICE: Pre-commit trigger called
ERROR: relation "bar" does not
On Mon, Nov 18, 2013 at 9:39 AM, Ian Lawrence Barwick wrote:
> postgres=# BEGIN ;
> BEGIN
> postgres=*# INSERT INTO foo (id) VALUES (1);
> INSERT 0 1
> postgres=*# COMMIT ;
> NOTICE: Pre-commit trigger called
> ERROR: relation "bar" does not exist
> LINE 1: SELECT foo FROM bar
>
Andrew Dunstan writes:
> Given that, do we want to keep the bar on these operating in single user
> mode? I can easily drop it and just document this way out of difficulty.
Currently Event Triggers are disabled in single user mode, in parts
because operating them require accessing to a catalog in
On 11/18/2013 09:39 AM, Ian Lawrence Barwick wrote:
Review for Andrew Dunstan's patch in CF 2013-11:
https://commitfest.postgresql.org/action/patch_view?id=1312
This review is more from a usage point of view, I would like
to spend more time looking at the code but only so many hours in a da
Review for Andrew Dunstan's patch in CF 2013-11:
https://commitfest.postgresql.org/action/patch_view?id=1312
This review is more from a usage point of view, I would like
to spend more time looking at the code but only so many hours in a day,
etcetera; I hope this is useful as-is.
Submission r
