2009/8/4 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 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.
>
> Well, probin is the wrong place for any such thing anyhow. Regardless
> of datatype issues, the system is clearly built on the assumption that
> the value of probin is to be specified *by the user* in CREATE FUNCTION.
> If you want a cache for derived information it would need to be a new
> column.
>
> (I remain of the opinion that caching such stuff in pg_proc would be
> a bad design decision. Every data structure that goes to disk is
> another data structure that you cannot easily change. There just isn't
> enough gain there to justify the maintenance headaches.)
ook, I agree - but I am not sure, so some cache will be necessary.
Pavel
>
> regards, tom lane
>
