Martijn van Oosterhout <kleptog@svana.org> writes: > On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote: >> You'd have to go over a lot of code with a fine-tooth comb before >> putting this ability into the hands of ordinary users, else you'd be >> creating loopholes for DOS attacks (or worse).
> Would it be reasonable to set this up so you can only create a shell > type within an explicit transaction and that you are required to define > the type completely before commit. I don't see any very easy way to enforce that, and it would break existing datatype-definition scripts if we did. However, since posting that it's occurred to me that we could do a lot to make the shell-type situation more robust. The problem with shell types is that the pg_type row is mostly left as zeroes, which means that any code that inspects the type without checking typisdefined is going to get a bogus value that may make it behave strangely. But we've since come up with a much better approach: see pseudotypes. We should set things up so that a shell type has valid but dummy entries in its pg_type row, including references to I/O functions that will just report an error if invoked. Also a shell type should be properly owned by its creator, which would let the creator drop it if it had been a mistake (right now, I think you can't get rid of it except by "DELETE FROM pg_type" :-(). With an arrangement like that, I'd feel much less worried about shell-type-related bugs. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly