Re: Chicken/egg problem with range types - Mailing list pgsql-general

From Tom Lane
Subject Re: Chicken/egg problem with range types
Date
Msg-id 14321.1342580904@sss.pgh.pa.us
Whole thread Raw
In response to Chicken/egg problem with range types  (Scott Bailey <artacus72@gmail.com>)
Responses Re: Chicken/egg problem with range types
Re: Chicken/egg problem with range types
List 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 by date:

Previous
From: raghu ram
Date:
Subject: Re: Problem running "ALTER TABLE...", ALTER TABLE waiting
Next
From: Adrian Klaver
Date:
Subject: Re: installation problem with postgres password