2009/8/4 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers