2009/8/4 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.)
I agree, so information about patch would be store in text field. But
I am not sure, if your fix isn't too simply. I haven't plan to compile
plpgsql to C or to binary code. But could be interesting link postgres
with some virtual machine like parrot or lua vm, and translate plpgsql
to p code. It's maybe far future.
Early future is integration main SQL parser to plpgsql. I am not sure,
but maybe we will need some persistent cache for store parametrized
sql queries. I though about store it in probin column.
Pavel
>
> regards, tom lane
>
