Re: pg_proc probin misuse

James William Pye <pgsql(at)jwp(dot)name> writes:
> I guess there are two ways to go about it. Simply remove the
> assumption that probin is only relevant to C functions; perhaps
> allowing a hardwired exception for builtin languages where allowing
> probin to be set would be deemed unsightly (ie, the easy way ;). Or,
> add a column to pg_language that specifies the language's probin usage
> so that pg_dump and the backend have an idea of how to handle these
> things for the given language(the "takes a bit more work" way). [I
> imagine the former could gracefully lead into the latter as well.]

I believe the reason interpret_AS_clause() is written the way that it is
is to provide some error checking, ie, not let the user specify a probin
clause for languages where it's not meaningful. That check predates the
invention of language validator functions, IIRC. It'd probably make
sense to get rid of the centralized check and expect the validator
functions to do it instead.

But we're still avoiding the central issue: does it make sense to dump a
probin clause at all for plpython functions? If it's a compiled form of
prosrc then it probably doesn't belong in the dump.

On reflection I'm kind of inclined to think that plpython is abusing the
column. If it were really expensive to derive bytecode from source text
then maybe it'd make sense to do what you're doing, but surely that's
not all that expensive. Everyone else manages to parse prosrc on the
fly and cache the result in memory; why isn't plpython doing that?

If we think that plpython is leading the wave of the future, I'd be kind
of inclined to invent a new pg_proc column in which derived text can be
stored, rather than trying to use probin for the purpose. Although
arguably probin itself was once meant to do that, there's too much
baggage now.

regards, tom lane