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
