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 und
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 writt
Andrew Dunstan 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 opinions about it
On Thu, Oct 22, 2009 at 10:12 AM, Andrew Dunstan 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
Dimitri Fontaine wrote:
I know I don't like #option because it looks and feels "foreign", so t
might just boils down to syntax issue for others too.
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
2009/10/22 Dimitri Fontaine :
> Tom Lane 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 abo
Tom Lane 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 language called plsq
2009/10/21 Tom Lane :
> Josh Berkus 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
On Wed, Oct 21, 2009 at 5:02 PM, Tom Lane wrote:
> Robert Haas 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 t
Josh Berkus 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 matter
> what the
Robert Haas 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 "error", but I don't
thi
On Wed, Oct 21, 2009 at 4:28 PM, Merlin Moncure wrote:
> On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus 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 fun
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus 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
> personally can't com
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 does
> 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?
Josh Berkus 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 fact, I'd go
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 i
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
On Wed, Oct 21, 2009 at 1:59 PM, Josh Berkus 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 users c
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
>>
>> 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 h
Pavel Stehule wrote:
> 2009/10/20 Tom Lane :
> > Merlin Moncure 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
> >> t
2009/10/20 Tom Lane :
> Merlin Moncure 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
Merlin Moncure 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 support a compatibili
On Tue, Oct 20, 2009 at 10:32 AM, Tom Lane wrote:
> Bruce Momjian 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 S
Bruce Momjian 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 things by
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; bu
Tom Lane wrote:
> Andrew Dunstan 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
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 it'l
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
"Eric B. Ridge" 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 to
"David E. Wheeler" 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 $$...$$;
> That is,
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 th
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, opt
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 e
"David E. Wheeler" 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
>> this but
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 by
Andrew Dunstan 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 backwards com
Merlin Moncure 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 a lot of attract
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
b
Tom Lane 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 an Oracle-compat
Robert Haas writes:
> On Mon, Oct 19, 2009 at 1:50 PM, 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'm afraid of it, I'm just not sure I have a better idea. It wouldn't
> bother me a bit if w
On Mon, Oct 19, 2009 at 1:50 PM, Tom Lane wrote:
> Pavel Stehule 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 ident
Pavel Stehule 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 good. But - there will
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane wrote:
> "David E. Wheeler" 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
> substan
On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane wrote:
> "David E. Wheeler" 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
> substan
2009/10/19 Kevin Grittner :
> "David E. Wheeler" 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
"David E. Wheeler" 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 care whether tha
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 proposal
"David E. Wheeler" 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 that "solve" the
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 issu
* 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,
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 suggest
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 th
On Mon, Oct 19, 2009 at 10:54 AM, Stephen Frost 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 behavior)
>
* 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 prob
On Sun, Oct 18, 2009 at 4:07 PM, Tom Lane wrote:
> Robert Haas 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 c
Robert Haas 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 #option line
or a GUC SET
On Sun, Oct 18, 2009 at 1:25 PM, 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 I
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
60 matches
Mail list logo
