Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2009/8/4 Tom Lane <tgl@sss.pgh.pa.us>:
>> I think that the least painful solution might be to change
>> pg_proc.probin to be declared as text.
> correct solution is moving the path to prosrc col or create new colum
> "externalproc". I thing so probin should be useful for plpgsql -
> sometime we should to store parser result from plpgsql compilation
> stage in this column. So my option is don't change native sense of
> this column. If we actually have not using, the we should to drop it,
> not create some breaks in future.
[ shrug... ] Can't get excited about it. What you propose would be a
significant amount of work and added complexity, because pg_dump or
somebody would have to take care to translate existing function
definitions properly. And the benefit is purely speculative.
I seriously doubt that serializing plpgsql compilation trees into a
bytea representation would be worth anyone's time. The original
Berkeley authors probably had some idea of storing compiled machine code
in probin, but nobody's done that either, and I'll bet long odds that
nobody ever will. (The advantage compared to external C functions
implemented as we currently know them seems negligible. The Berkeley
folk probably did not foresee the prevalence of loadable-shared-library
support, nor the general security-driven move away from allowing
execution of writable memory.)
regards, tom lane
