Re: Chicken/egg problem with range types
От | Tom Lane |
---|---|
Тема | Re: Chicken/egg problem with range types |
Дата | |
Msg-id | 14321.1342580904@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Chicken/egg problem with range types (Scott Bailey <artacus72@gmail.com>) |
Ответы |
Re: Chicken/egg problem with range types
Re: Chicken/egg problem with range types |
Список | pgsql-general |
Scott Bailey <artacus72@gmail.com> writes: > I'm trying to create a discrete range type and I'm having trouble with > the canonical function. Yeah, right now you really can't write canonical functions in anything except C, for which we don't enforce the no-shell-types restriction. Before range types, this wasn't a big deal since it was only an issue for I/O functions, which pretty much have to be in C anyway. But your example shows that at least for prototyping, a SQL or PL function could usefully be used as a canonical function. I wonder whether we could improve this by postponing the no-shell-types check from creation to function runtime. It would be annoying to have to make an additional catalog lookup at runtime just for typisdefined, but I think that probably we could fold it in with an existing fetch of the pg_type row during parsing of the calling query, so that no run-time overhead is added. This would limit what checking could be performed on the function body at creation time, but surely no worse than, say, a reference to a nonexistent table, which we allow. Another thing that would have to be thought about is security: external PLs would very possibly not get the word about needing to check for shell arguments/results themselves, and we'd need to make certain that nothing too awful could happen if they didn't. That doesn't seem insoluble but it would take some thought. A different security angle is making sure that nothing too awful happens if someone tries to use a SQL or PL function as a type I/O function, which would now not be forbidden by the no-shell-types restriction. regards, tom lane
В списке pgsql-general по дате отправления: