Tom Lane wrote:
Under old-style semantics this will do what the programmer thought.
Under Oracle semantics it will return the first table row. If
do-something is security critical then this is enough to call it
an exploit. The reverse direction (code meant for Oracle behavior
breaks under
On Tue, 2009-10-20 at 10:32 -0400, Tom Lane wrote:
That's only sane if you are 100% certain that there could not be a
security issue arising from the change of behavior. Otherwise someone
could for instance subvert a security-definer function by running it
under the setting it wasn't written
Tom Lane t...@sss.pgh.pa.us writes:
be seen as one.) And the Oracle-compatible option will be attractive
to people coming in from that side. Reviewing megabytes of pl/sql
code for this kind of gotcha is not fun, and the error default would
only help a bit.
What about having a new pl
2009/10/22 Dimitri Fontaine dfonta...@hi-media.com:
Tom Lane t...@sss.pgh.pa.us writes:
be seen as one.) And the Oracle-compatible option will be attractive
to people coming in from that side. Reviewing megabytes of pl/sql
code for this kind of gotcha is not fun, and the error default would
On Thu, Oct 22, 2009 at 10:12 AM, Andrew Dunstan and...@dunslane.net wrote:
Let's not get too hung up on syntax.
+1.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan and...@dunslane.net writes:
I don't see why it feels any more foreign than, say, #pragma in C.
And it's something we already have, albeit undocumented.
Let's not get too hung up on syntax.
Ok just wanted to have this syntax part explicitely talked about, I
don't have strong
Tom,
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged users can't break things by twiddling it; but it's still
possible for
On Wed, Oct 21, 2009 at 1:59 PM, Josh Berkus j...@agliodbs.com wrote:
Tom,
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged
On Oct 21, 2009, at 11:37 AM, Robert Haas wrote:
That's like saying that it's less of a risk than a group of rabid
tyrannosaurs in a kindergarten classroom.
I'm not sure, but I kind of doubt that tyrannosaurs can get rabies. I
mean, if they were even around anymore. Which, you know, they're
Robert,
H. I don't see any reason why this couldn't be set by any user at
runtime, really. From a security standpoint, it's less of a risk than
search_path, and we allow anyone to mess with that.
That's like saying that it's less of a risk than a group of rabid
tyrannosaurs in a
Josh Berkus j...@agliodbs.com writes:
Making this GUC suset would make it far less useful to users trying to
gradually upgrade their infrastructures, and make it more likely that
many/most of our users would just set it to backwards-compatible in
their postgresql.conf and not fix anything. In
That's what the #option alternative is for. Yes, it's a bit ugly, but
it's perfectly functional, and secure too.
I still don't see why it's needed. If the function owner simply sets
the option in the function definitions (as a userset), it doesn't matter
what the calling user sets, does it?
On 10/21/09 1:02 PM, Josh Berkus wrote:
That's what the #option alternative is for. Yes, it's a bit ugly, but
it's perfectly functional, and secure too.
I still don't see why it's needed. If the function owner simply sets
the option in the function definitions (as a userset), it doesn't
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
Tom has proposed some kind of odd special options syntax to get around
this, but I think that's unnecessary. So far on this thread, I haven't
seen anyone engineer an actual function exploit by using this setting; I
On Wed, Oct 21, 2009 at 4:28 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
Tom has proposed some kind of odd special options syntax to get around
this, but I think that's unnecessary. So far on this thread, I haven't
seen
Robert Haas robertmh...@gmail.com writes:
I actually think that we should not have a GUC for this at all. We
should have a compiled-in default, and it should be error. If you
want some other behavior, decorate your functions with #option.
We've agreed that the factory default should be
Josh Berkus j...@agliodbs.com writes:
That's what the #option alternative is for. Yes, it's a bit ugly, but
it's perfectly functional, and secure too.
I still don't see why it's needed. If the function owner simply sets
the option in the function definitions (as a userset), it doesn't
On Wed, Oct 21, 2009 at 5:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I actually think that we should not have a GUC for this at all. We
should have a compiled-in default, and it should be error. If you
want some other behavior, decorate your functions
2009/10/21 Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com writes:
Making this GUC suset would make it far less useful to users trying to
gradually upgrade their infrastructures, and make it more likely that
many/most of our users would just set it to backwards-compatible in
their
Bruce Momjian wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged users can't break things by twiddling it; but it's
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be throw-error. Make it SUSET so that
unprivileged users can't break
On Tue, Oct 20, 2009 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory default,
at least for a few releases, will be
Merlin Moncure mmonc...@gmail.com writes:
How about warning for release before making the big switch? The text
cast change, while ultimately good, maybe could have been stretched
out for a release or two...it was painful. I do though absolutely
think that it was good in the end to not
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
How about warning for release before making the big switch? The text
cast change, while ultimately good, maybe could have been stretched
out for a release or two...it was painful. I do though absolutely
think
Pavel Stehule wrote:
2009/10/20 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
How about warning for release before making the big switch? ?The text
cast change, while ultimately good, maybe could have been stretched
out for a release or two...it was painful. ?I do
I don't thing, so drop some implicit-casts was huge problem. Somebody
could to use Peter's patch, that recreate missing casts.
True, but we should have had those compatibility pathes (Peter's patch)
ready before we released, and advertised them in the release notes.
sure
Maybe we have to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think there are basically three behaviors that we could offer:
1. Resolve ambiguous names as plpgsql (historical PG behavior)
2. Resolve ambiguous names as query column (Oracle behavior)
3. Throw error if name is ambiguous (useful for finding
On Mon, Oct 19, 2009 at 10:54 AM, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think there are basically three behaviors that we could offer:
1. Resolve ambiguous names as plpgsql (historical PG behavior)
2. Resolve ambiguous names as query column (Oracle
On Oct 19, 2009, at 7:54 AM, Stephen Frost wrote:
4. Resolve ambiguous names as query column, but throw warning
#4 would be my vote, followed by #3. To be perfectly honest, I'd be a
whole lot happier with a pl/pgsql that let me prefix variable names
with
a '$' or similar to get away from
On Oct 19, 2009, at 8:36 AM, Robert Haas wrote:
I think warnings are too easy to miss, but I agree your other
suggestion. I know you can write function_name.variable_name, but
that's often massively long-winded. We either need a short, fixed
prefix, or some kind of sigil. I previously
* David E. Wheeler (da...@kineticode.com) wrote:
On Oct 19, 2009, at 8:36 AM, Robert Haas wrote:
I think warnings are too easy to miss, but I agree your other
suggestion. I know you can write function_name.variable_name, but
that's often massively long-winded. We either need a short, fixed
On Oct 19, 2009, at 9:29 AM, Stephen Frost wrote:
Uh, what dollar quoting? $_$ is what I typically use, so I wouldn't
expect a $ prefix to cause a problem. I think it'd be more of an
issue
because pl/pgsql still uses $1 and whatnot internally (doesn't it?).
Yes, but that's no more an
David E. Wheeler da...@kineticode.com writes:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in plpgsql. I have got
substantially less than zero interest in proposals
On Oct 19, 2009, at 9:49 AM, Tom Lane wrote:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in plpgsql. I have got
substantially less than zero interest in
David E. Wheeler da...@kineticode.com wrote:
I'd be in favor of a GUC that I could turn on to throw an error
when there's an ambiguity.
I would consider hiding one definition with another very bad form, so
I would prefer to have plpgsql throw an error when that happens. I
don't particularly
2009/10/19 Kevin Grittner kevin.gritt...@wicourts.gov:
David E. Wheeler da...@kineticode.com wrote:
I'd be in favor of a GUC that I could turn on to throw an error
when there's an ambiguity.
I would consider hiding one definition with another very bad form, so
I would prefer to have plpgsql
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in
Pavel Stehule pavel.steh...@gmail.com writes:
ambiguous identifiers is probably the top reason of some plpgsql's
mysterious errors. More times I found wrong code - sometime really
important (some security checks). I never found good code with
ambiguous identifiers - so for me, exception is
On Mon, Oct 19, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
ambiguous identifiers is probably the top reason of some plpgsql's
mysterious errors. More times I found wrong code - sometime really
important (some security checks). I never
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 19, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC. (I still think you're all wrong, but so be it.)
I'm afraid of it, I'm just not sure I have a better idea.
Tom Lane t...@sss.pgh.pa.us wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC.
Well, it seems dangerous to me, but I'm confident we can cover this
within our shop, so I'm reluctant to take a position on it. I guess
the main question is whether we want to allow
Tom Lane wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC. (I still think you're all wrong, but so be it.)
I can't say I'm happy about it. For one thing, the granularity seems all
wrong. I'd rather be able to keep backwards compatibility on a function
Merlin Moncure mmonc...@gmail.com writes:
Maybe invent a new language handler? plpgsql2 or shorten to pgsql?
Now you can mess around all you want (and maybe fix some other
compatibility warts at the same time).
Well, pl/psm is out there, and might even make it into core someday.
I don't find
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC. (I still think you're all wrong, but so be it.)
I can't say I'm happy about it. For one thing, the granularity seems all
wrong. I'd rather be able to keep
On Oct 19, 2009, at 11:47 AM, Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory
default,
at least for a few releases, will be throw-error. Make it SUSET so
that
unprivileged users can't break things
David E. Wheeler da...@kineticode.com writes:
On Oct 19, 2009, at 11:47 AM, Tom Lane wrote:
2. Also invent a #option syntax that allows the GUC to be overridden
per-function. (Since the main GUC is SUSET, we can't just use a
per-function SET to override it. There are other ways we could do
On Oct 19, 2009, at 2:47 PM, Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory
default,
at least for a few releases, will be throw-error.
Sorry if this is obvious to everyone else, but *when* will the
On Oct 19, 2009, at 12:05 PM, Tom Lane wrote:
What about adopting the modifier syntax you're adding to COPY?
Where exactly would you put the modifier, and why is that better than
the existing #option convention?
CREATE OR REPLACE FUNCTION foo()
RETURNS BOOLEAN
LANGUAGE plpgsql WITH opt1,
I wrote:
Where exactly would you put the modifier, and why is that better than
the existing #option convention?
BTW, it occurs to me that since that's undocumented, not everyone might
know what I'm talking about. There's some code in plpgsql that allows
you to write
#option dump
at the
David E. Wheeler da...@kineticode.com writes:
On Oct 19, 2009, at 12:05 PM, Tom Lane wrote:
Where exactly would you put the modifier, and why is that better than
the existing #option convention?
CREATE OR REPLACE FUNCTION foo()
RETURNS BOOLEAN
LANGUAGE plpgsql WITH opt1, opt2
AS $$...$$;
Eric B. Ridge e...@tcdi.com writes:
On Oct 19, 2009, at 2:47 PM, Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory
default,
at least for a few releases, will be throw-error.
Sorry if this is obvious
On Oct 19, 2009, at 12:23 PM, Tom Lane wrote:
That is, the specification of options is made outside of the language
in question.
I don't think I particularly care for this. It's inventing a global
mechanism to cover a problem that we currently have one instance of
in one PL. That's a mighty
On Oct 19, 2009, at 3:46 PM, Tom Lane wrote:
Sorry if this is obvious to everyone else, but *when* will the error
throw?
Whenever we do semantic analysis of the particular query or
expression.
That's what I figured.
During CREATE FUNCTION or during runtime? I'm secretly hoping
that
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
(a) Nobody but me is afraid of the consequences of treating this as
a GUC. (I still think you're all wrong, but so be it.)
I can't say I'm happy about it. For one thing, the granularity seems all
wrong. I'd
As most of you will recall, plpgsql currently acts as though identifiers
in SQL queries should be resolved first as plpgsql variable names, and
only failing that do they get processed as names of the query. The
plpgsql parser rewrite that I'm working on will fix that for the
obviously-silly cases
On Sun, 2009-10-18 at 13:25 -0400, Tom Lane wrote:
As most of you will recall, plpgsql currently acts as though identifiers
in SQL queries should be resolved first as plpgsql variable names, and
only failing that do they get processed as names of the query. The
plpgsql parser rewrite that
On Sun, Oct 18, 2009 at 1:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As most of you will recall, plpgsql currently acts as though identifiers
in SQL queries should be resolved first as plpgsql variable names, and
only failing that do they get processed as names of the query. The
plpgsql parser
Robert Haas robertmh...@gmail.com writes:
If possible, I think we should try to engineer things so that using
pg_dump 8.5 on an 8.4 database and restoring the result into an 8.5
database produces a function with identical semantics.
Hmm ... actually, we could have pg_dump stick either a
On Sun, Oct 18, 2009 at 4:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If possible, I think we should try to engineer things so that using
pg_dump 8.5 on an 8.4 database and restoring the result into an 8.5
database produces a function with identical
60 matches
Mail list logo
