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