2009/8/4 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2009/8/4 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>