Re: Possible SET SESSION AUTHORIZATION bug
От | Chris Ochs |
---|---|
Тема | Re: Possible SET SESSION AUTHORIZATION bug |
Дата | |
Msg-id | 00c701c457be$8aa63e50$250a8b0a@chris обсуждение исходный текст |
Ответ на | Possible SET SESSION AUTHORIZATION bug ("Chris Ochs" <chris@paymentonline.com>) |
Список | pgsql-general |
On my system I get permission denied when I switch to pgtest2 and select * from pgtest_func. Chris -- create objects -- CREATE USER pgtest1 WITH ENCRYPTED PASSWORD 'pass' NOCREATEDB NOCREATEUSER; CREATE USER pgtest2 WITH ENCRYPTED PASSWORD 'pass' NOCREATEDB NOCREATEUSER; CREATE SCHEMA pgtest1 AUTHORIZATION pgtest1; CREATE SCHEMA pgtest2 AUTHORIZATION pgtest2; CREATE OR REPLACE FUNCTION pgtest_func() returns integer AS ' DECLARE in_test varchar; BEGIN in_test := test FROM pgtest_table; RETURN 1; END ' LANGUAGE 'plpgsql'; SET SESSION AUTHORIZATION pgtest1; SET SEARCH_PATH TO pgtest1,public; CREATE TABLE pgtest_table ( test varchar(24) ); INSERT INTO pgtest_table(test) values('PGTEST1'); RESET SESSION AUTHORIZATION; SET SESSION AUTHORIZATION pgtest2; SET SEARCH_PATH TO pgtest2,public; CREATE TABLE pgtest_table ( test varchar(24) ); INSERT INTO pgtest_table(test) values('PGTEST2'); -- switch to pgtest1 and run pgtest_func -- RESET SESSION AUTHORIZATION; SET SESSION AUTHORIZATION pgtest1; SET SEARCH_PATH TO pgtest1,public; SELECT * from pgtest_func(); -- switch to pgtest2 and run pgtest_func -- RESET SESSION AUTHORIZATION; SET SESSION AUTHORIZATION pgtest2; SET SEARCH_PATH TO pgtest2,public; SELECT * from pgtest_func(); RESET SESSION AUTHORIZATION; DROP USER pgtest1; DROP USER pgtest2; DROP SCHEMA pgtest1 CASCADE; DROP SCHEMA pgtest2 CASCADE; DROP FUNCTION pgtest_func(); ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Chris Ochs" <chris@paymentonline.com> Cc: <pgsql-general@postgresql.org> Sent: Monday, June 21, 2004 9:25 AM Subject: Re: [GENERAL] Possible SET SESSION AUTHORIZATION bug > "Chris Ochs" <chris@paymentonline.com> writes: > > Ok this probably isn't a bug but a side affect of how functions are cached. > > Changing the function to use EXECUTE to perform the query works. I don't > > know if this particular scenario was ever even though of before, or if in > > the future it would make sense to have the query planner not cache the > > session user/current user? > > It doesn't cache that. I'm not sure what's going on here ... could you > provide a self-contained test script? > > regards, tom lane >
В списке pgsql-general по дате отправления: