Scott Bailey <artacu...@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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
