Re: Should creating a new base type require superuser status?
От | Tom Lane |
---|---|
Тема | Re: Should creating a new base type require superuser status? |
Дата | |
Msg-id | 23742.1217453388@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Should creating a new base type require superuser status? (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Should creating a new base type require superuser status?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: