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
Pavel Stehule escribió:
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
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
pg_proc.probin is currently declared as being type bytea. Perhaps that
had some real utility once upon a time, but no currently defined
procedural language stores binary data there. In fact, the only
thing that gets stored there is the shared-library file name for
C functions. To make things
On Mon, Aug 3, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us wrote:
pg_proc.probin is currently declared as being type bytea. Perhaps that
had some real utility once upon a time, but no currently defined
procedural language stores binary data there. In fact, the only
thing that gets stored
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 3, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I think that the least painful solution might be to change
pg_proc.probin to be declared as text. Otherwise we're going to need
version-specific klugery in pg_dump and who knows where
On Mon, Aug 03, 2009 at 10:03:11PM -0400, Tom Lane wrote:
However, with the hex bytea output patch in place, it's *completely*
broken. I offer the following pg_dump output:
CREATE FUNCTION interpt_pp(path, path) RETURNS point
LANGUAGE c
AS
On Mon, Aug 3, 2009 at 10:40 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 3, 2009 at 10:03 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I think that the least painful solution might be to change
pg_proc.probin to be declared as text. Otherwise we're
2009/8/4 Tom Lane t...@sss.pgh.pa.us:
pg_proc.probin is currently declared as being type bytea. Perhaps that
had some real utility once upon a time, but no currently defined
procedural language stores binary data there. In fact, the only
thing that gets stored there is the shared-library
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
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
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
12 matches
Mail list logo
