Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> 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
callthat a bug or design flaw, which has to be fixed. Just preventing an invalid search path resulting from a
rollbackoperation 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. #
#================================================== JanWieck@Yahoo.com #
