Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
От | Amit Kapila |
---|---|
Тема | Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block |
Дата | |
Msg-id | CAA4eK1Ls8ExPrTAGzFYND3-_yBtSuv7sRVaGVsG8iOZucUt8yQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Suggestion: Issue warning when calling SET
TRANSACTION outside transaction block
|
Список | pgsql-hackers |
On Thu, Oct 3, 2013 at 8:35 PM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2013-09-30 22:19:31 -0400, Bruce Momjian wrote: >> On Sun, Sep 29, 2013 at 11:40:51AM +0530, Amit Kapila wrote: >> > >> Shouldn't we do it for Set Constraints as well? >> > > >> > > Oh, very good point. I missed that one. Updated patch attached. >> >> I am glad you are seeing things I am not. :-) >> >> > 1. The function set_config also needs similar functionality, else >> > there will be inconsistency, the SQL statement will give error but >> > equivalent function set_config() will succeed. >> > >> > SQL Command >> > postgres=# set local search_path='public'; >> > ERROR: SET LOCAL can only be used in transaction blocks >> > >> > Function >> > postgres=# select set_config('search_path', 'public', true); >> > set_config >> > ------------ >> > public >> > (1 row) >> >> I looked at this but could not see how to easily pass the value of >> 'isTopLevel' down to the SELECT. All the other checks have isTopLevel >> passed down from the utility case statement. > > Doesn't sound like a good idea to prohibit that anyway, it might > intentionally be used as part of a more complex statement where it only > should take effect during that single statement. Agreed and I think it is good reason for not changing behaviour of set_config(). With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: