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])