Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
On Mon, 2008-11-17 at 19:34 -0500, Tom Lane wrote:
My point is it's a user-visible change --- maybe a subtle one, but still
a change that in principle could break some app somewhere --- and no
good reason has been put forward for making it.
Uhh... what user is going to be calling pg_catalog.xmlconcat() in any
version?
Anybody wanting to ensure that they got the system version of the
function rather than some other version. In 8.3 that wasn't necessary
because the function had a special production, but with this change
schema-qualification would become *necessary* for anyone wanting to
avoid search path gotchas. So arguably we'd be creating a security hole
that wasn't there in 8.3. Immediately visible breakage would probably
only happen in the other direction, ie trying to run an 8.4 app on 8.3.
I still haven't heard an argument what's the value of changing it, anyway.
Well, if that is the attitude, then there is never going to be any
purpose or incentive to generalized hard-coded hacks into generalized
features. Moreover, what is the point of extensibility if the system
itself cannot use it.
If you think the scenario you describe above is relevant, then perhaps
people shouldn't be allow to override system objects in the first place.
Because this security hole pretty much exits today already: Anyone can
place an object in the public schema, and in reality hardly anyone
schema-qualifies system objects. If you are trying to be sneaky, you
place your own versions of functions added in 8.4 into 8.3, let the
admin upgrade and then let him try out all this great new functionality
of 8.4 based on your "versions". I am not sure what our response to
this is, but creating a singular solution for xmlconcat is probably not
sufficient.
If you think about it, the default search path of
public, pg_catalog
is in Unix terms equivalent to a default path -- for everyone, including
root -- of
~user1/bin:~user2/bin:...:~userN/bin:/usr/bin:/bin
Maybe the relative placements of these things needs to be rethought.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
