Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Peter Eisentraut wrote: > Tom Lane wrote: > > plpgsql does not consider standard_conforming_strings --- it still uses > > backslash escaping in its function bodies regardless. Since the > > language itself is not standardized, I see no particular reason that > > standard_conforming_strings should govern it. > > I think plpgsql should behave either consistently with the rest of PostgreSQL > or with Oracle, which it is copied from. > > > I believe the reason for > > not changing it was that it seemed too likely to break existing > > functions, with potentially nasty consequences if they chanced to be > > security definers. > > Is this actually true or did we just forget it? :-) Did we ever address this? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Peter Eisentraut wrote: > Tom Lane wrote: > > plpgsql does not consider standard_conforming_strings --- it still uses > > backslash escaping in its function bodies regardless. Since the > > language itself is not standardized, I see no particular reason that > > standard_conforming_strings should govern it. > > I think plpgsql should behave either consistently with the rest of PostgreSQL > or with Oracle, which it is copied from. > > > I believe the reason for > > not changing it was that it seemed too likely to break existing > > functions, with potentially nasty consequences if they chanced to be > > security definers. > > Is this actually true or did we just forget it? :-) I would like to add a TODO item for this, but I am concerned that people running functions with different standard_conforming_strings values would have function syntax errors on mismatch. Is that acceptable? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Agreed. standard_conforming_strings should affect _all_ strings. > > We might need another transition period over a few releases with a > separate "plpgsql_standard_conforming_strings" parameter. Just changing it > immediately is perhaps a bit risky. We haven't even enabled standard_conforming_strings by default yet. It was added as changeable in 8.2. Is this never going to be enabled by default? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Bruce Momjian wrote: > Agreed. standard_conforming_strings should affect _all_ strings. We might need another transition period over a few releases with a separate "plpgsql_standard_conforming_strings" parameter. Just changing it immediately is perhaps a bit risky. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Peter Eisentraut wrote: > Tom Lane wrote: > > plpgsql does not consider standard_conforming_strings --- it still uses > > backslash escaping in its function bodies regardless. Since the > > language itself is not standardized, I see no particular reason that > > standard_conforming_strings should govern it. > > I think plpgsql should behave either consistently with the rest of PostgreSQL > or with Oracle, which it is copied from. Agreed. standard_conforming_strings should affect _all_ strings. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I believe the reason for >> not changing it was that it seemed too likely to break existing >> functions, with potentially nasty consequences if they chanced to be >> security definers. > Is this actually true or did we just forget it? :-) I recall thinking about the point. The decision could've been wrong ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
Tom Lane wrote: > plpgsql does not consider standard_conforming_strings --- it still uses > backslash escaping in its function bodies regardless. Since the > language itself is not standardized, I see no particular reason that > standard_conforming_strings should govern it. I think plpgsql should behave either consistently with the rest of PostgreSQL or with Oracle, which it is copied from. > I believe the reason for > not changing it was that it seemed too likely to break existing > functions, with potentially nasty consequences if they chanced to be > security definers. Is this actually true or did we just forget it? :-) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql
"Jonathan Guthrie" <[EMAIL PROTECTED]> writes: > I have set the standard_conforming_strings to "on" in my settings ... > However, when I attempt to define this function: > create function foo (out r refcursor) as $bar$ > begin > open r for >select * from user_data >where name_first like name escape '\'; > end; $bar$ language plpgsql; plpgsql does not consider standard_conforming_strings --- it still uses backslash escaping in its function bodies regardless. Since the language itself is not standardized, I see no particular reason that standard_conforming_strings should govern it. I believe the reason for not changing it was that it seemed too likely to break existing functions, with potentially nasty consequences if they chanced to be security definers. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
