Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Is an invalid search path really that critical (read security
> > issue)?
>
> It's not a security issue (unless the OID counter wraps around soon
> enough to let someone else get assigned the same OID for a namespace).
> But it could be pretty annoying anyway, because the front element of
> the search path is also the default creation target namespace. You
> could create a bunch of tables and then be unable to access them later
> for lack of a way to name them.
>
> I'm not really excited about establishing positive interlocks across
> backends to prevent DROPping a namespace that someone else has in their
> search path ... but I do want to handle the simple local-effect cases,
> like rollback of creation of a namespace.
How are namespaces different from any other objects? Can I
specify a foreign key reference to a table that was there at
some time in the past? Can I create a view using functions
that have been there last week? Sure, I can break those
objects once created by dropping the underlying stuff, but
that's another issue.
If namespace dropping allows for creation of objects that
cannot be dropped afterwards any more, I would call that a
bug or design flaw, which has to be fixed. Just preventing an
invalid search path resulting from a rollback operation like
in your example is totally insufficient.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
