Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Morten Hustveit <morten(at)eventures(dot)vc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Date: 2013-02-03 07:19:14
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C38420CB739@szxeml558-mbs.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Saturday, February 02, 2013 9:08 PM Robert Haas wrote:
On Fri, Feb 1, 2013 at 12:04 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> I think user should be aware of effect before using SET commands, as these are used at various levels (TRANSACTION, SESSION, ...).

> Ideally, sure. But these kinds of mistakes are easy to make.

You mean to say that after using SET Transaction, user can think below statements will
use modified transaction property. But I think if user doesn't understand by default
transaction will be committed after the statement execution, he might expect after
few statements he can rollback.

> That's why LOCK and DECLARE CURSOR already emit errors in this case - why
> should this one be any different?

IMO, I think error should be given when it is not possible to execute current statement.

Not only LOCK,DECLARE CURSOR but SAVEPOINT and some other statements also give the same error,
so if we want to throw error for such behavior, we can find all such similar statements
(SET TRANSACTION, SET LOCAL, etc) and do it for all.

This can be helpful to some users, but not sure if such behavior (statement can be executed but it will not have any sense)
can be always detectable and maintaible.

With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Phil Sorber 2013-02-03 07:23:05 Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq
Previous Message Magnus Hagander 2013-02-03 06:37:14 Re: [PATCH] Add PQconninfoParseParams and PQconninfodefaultsMerge to libpq