Re: timeout implementation issues

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 #