Prev: per table random-page-cost?
Next: UTF8 with BOM support in psql
From: Bruce Momjian on 20 Oct 2009 01:41
Tom Lane wrote:
> Andrew Dunstan <andrew(a)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 backwards compatibility on a function
> > by function basis. Or would the value of the GUC at the time the
> > function was created stick?
>
> Again, I can't see making a GUC that works fundamentally differently
> from the rest of them.
>
> Given this round of feedback, I make the following proposal:
>
> 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 the DBA to set it per-database or per-user.
>
> 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 none seem less ugly than #option...)

I don't see the logic to making the setting SUSET. The user wrote the
function; what logic is there to say the resolution rules are not under
their control?

Also, I think to GUC that throws an error or not is a lot safer than one
that changes resolution semantics. Changing resolution semantics sounds
like the autocommit GUC to me. :-O

Also, I am not really keen on the "keep it for a few releases" --- we
often don't come back to finally change it, so maybe just error/no error
and using Oracle semantics is the way to go, with 'error' as the
default. Our change in casting for 8.3 seemed much more major than
this.

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Bruce Momjian on 20 Oct 2009 02:21
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 still
> > possible for the DBA to set it per-database or per-user.
> >
> > 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 none seem less ugly than #option...)
>
> I don't see the logic to making the setting SUSET. The user wrote the
> function; what logic is there to say the resolution rules are not under
> their control?
>
> Also, I think to GUC that throws an error or not is a lot safer than one
> that changes resolution semantics. Changing resolution semantics sounds
> like the autocommit GUC to me. :-O
>
> Also, I am not really keen on the "keep it for a few releases" --- we
> often don't come back to finally change it, so maybe just error/no error
> and using Oracle semantics is the way to go, with 'error' as the
> default. Our change in casting for 8.3 seemed much more major than
> this.

Oh, two more things. First, with the Oracle resolution rules, I think
it is possible to change the behavior of a function by adding or
renaming a column that wasn't referenced in the function because a
new/renamed column might mask a function variable --- that is not nice.

Second, I can see the value of having the GUC be SUSET if changing the
setting could possible break the function or cause insecure behavior,
but I wasn't clear that was possible.

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Bruce Momjian on 20 Oct 2009 13:07
Pavel Stehule wrote:
> 2009/10/20 Tom Lane <tgl(a)sss.pgh.pa.us>:
> > Merlin Moncure <mmoncure(a)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 support a compatibility
> >> option in core.
> >
> > As long as we provide a backwards-compatible setting, I don't believe
> > this change will be a huge deal. ?The problem with the implicit-casts
> > business was that there was no reasonable way to provide a control
> > switch --- the catalog entries were either there or not :-(. ?So far
> > as I can tell at the moment, there won't be any large technical cost
> > to providing a backwards-compatible option for this plpgsql change.
>
> 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.

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Bruce Momjian on 9 Nov 2009 18:17
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 old-style) is not difficult to cons up either; I think
> you can find some examples in pgsql-bugs archives from people trying
> to port Oracle code to PG.
>
> Given that people are very prone to intentionally naming things as above
> (for a particularly egregious example try
> http://archives.postgresql.org/pgsql-bugs/2009-10/msg00054.php)
> I think it's entirely foolish to imagine this isn't a real hazard.
> If name collisions were improbable we'd not have so many complaints
> about the current behavior in our archives, and probably wouldn't be
> thinking about changing the behavior at all.

Sorry for the late reply:

Stepping back a bit, is there something we can do to reduce the chances
of variable-name collision? If you are selecting a column called
"first_name", it is logical to put it into a variable called
"first_name", and hence the conflict if that variable is used in a
query.

I know some Oracle people use a 'v_' prefix for variables, but that
always looked ugly to me. Is there something else we could use to
qualify variables used in queries to avoid conflicts?

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: per table random-page-cost?
Next: UTF8 with BOM support in psql