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