Gregory Stark <stark@enterprisedb.com> writes:
> I know when I was first starting out it was a big source of frustration that
> you have to get those arguments right.. Until I figured out what they all
> meant and how to use them I was constantly crashing the server.
> It seems to me we should be able to do better. To have some kind of struct in
> the C code associated with the input/output functions from which the create
> type command picks up these parameters.
And what are the odds that you'll get it right in a C struct if you
couldn't get it right in the SQL command? There might be some small
advantage here from a packaging standpoint, but I think the argument
that it'd help novice PG hackers is bogus.
> As a consequence we could perhaps aim to make creating new types safe rather
> than just deal with the fact that it's not safe currently? It would be nice if
> non-superusers could create types which used an existing set of input/output
> functions but defined new semantics.
Unless you're going to allow them to create new C functions, I'm not
clear on how much they're going to be able to change the semantics.
>> * The just-added ability to specify a new type's type category and
>> "preferred" status could allow subverting the behavior of existing
>> queries that expect ambiguous operators to be resolved in a particular
>> way. A new preferred type could "capture" such queries and thereby
>> provide a trojan-horse vector for executing functions as some other
>> user.
> Would it be enough to only require super-user to create a preferred type?
Well, it'd close one hole, but I think there are too many others to
take a narrow-gauge approach.
regards, tom lane
