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
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
61 matches
Mail list logo
