Re: pg_proc.probin should become text?

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.)

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
>