Scott Bailey <artacus72@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
