Re: pg_proc.probin should become text? - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: pg_proc.probin should become text?
Date
Msg-id 162867790908040758m42bdbbs4b23b4a54731c18b@mail.gmail.com
Whole thread Raw
In response to Re: pg_proc.probin should become text?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: More portable way to support 64bit platforms
Next
From: Andrew Dunstan
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Cause pg_proc.probin to be declared as text, not bytea.