[BUGS] Re: [NOVICE] RE: iofflush psql 7.0.3 coredump on RH 6.1
Rasputin <[EMAIL PROTECTED]> writes: > In this case, disabling readline starts up the client OK. > I'll try upgrading readline on this system ,and see what happens. I was just going to suggest that. Did you compile Postgres from source, or is this an assemblage of RPMs? There have been enough different versions of libreadline distributed that I wouldn't be surprised to find out that our RPMs are not compatible with some of 'em. But I dunno whether the RPMs are marked with sufficiently tight dependency info. If you find that a newer libreadline fixes it, we'd like to know what the old and new libreadline versions are ... regards, tom lane
[BUGS] dump of functions does not handle backslashes correctly
If you create a function from psql like: CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS '/usr/local/pgsql/lib/plpgsql.so' LANGUAGE 'C'; CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler" LANCOMPILER 'PL/pgSQL'; CREATE FUNCTION "atestfun" ( ) RETURNS text AS 'DECLARE mtt TEXT; BEGIN mtt := ''This is a test.''; RETURN mtt; END;' LANGUAGE 'plpgsql'; Then use pg_dump on it, you get: CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS '/usr/local/pgsql/lib/plpgsql.so' LANGUAGE 'C'; CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler" LANCOMPILER 'PL/pgSQL'; CREATE FUNCTION "atestfun" ( ) RETURNS text AS 'DECLARE mtt TEXT; BEGIN mtt := ''This is a \\ test.''; RETURN mtt; END;' LANGUAGE 'plpgsql'; In the function, the variable "mtt" loses half of the '\' characters. When you reload this dump, the embedded '\' is lost. When you do a SELECT atestfun(); The ouput should be: atestfun -- This is a \ test. (1 row) But instead, it returns: atestfun -- This is a test. (1 row) Is this a pg_dump bug or is there there some way to do this right? -- Robert B. Easter [EMAIL PROTECTED] - - CompTechNews Message Board http://www.comptechnews.com/ - - CompTechServ Tech Services http://www.comptechserv.com/ - -- http://www.comptechnews.com/~reaster/
[BUGS] Re: [NOVICE] RE: iofflush psql 7.0.3 coredump on RH 6.1
Rasputin <[EMAIL PROTECTED]> writes: >> If you find that a newer libreadline fixes it, we'd like to know what >> the old and new libreadline versions are ... > It did. > The offender was readline-4.0.1 > (to be fair I don't think it's the default on 6.1 - STR upgrading it to > fix *another* bug while installing gnome-1.2) > Installing 4.1 fixed it. Odd. I'm using 4.0 here without any difficulty, and I don't recall anyone reporting similar problems with recent readlines (I was afraid you had a 2.something version...). Has anyone else seen a problem with 4.0.1? regards, tom lane
Re: [BUGS] Re: [NOVICE] RE: iofflush psql 7.0.3 coredump on RH 6.1
> Odd. I'm using 4.0 here without any difficulty, and I don't recall > anyone reporting similar problems with recent readlines (I was afraid > you had a 2.something version...). Has anyone else seen a problem with > 4.0.1? We just ran across a problem with 3.x vs 4.x libraries when installing an RPM package for another project. There were a few unresolved symbols in 4.0 that seem to be available in another library, but I haven't heard how we finally resolved it. Is this related to your symptom? - Thomas
[BUGS] inserting binary in a bytea field
POSTGRESQL BUG REPORT TEMPLATE
Your name : Olivier Jeannet
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.13
PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.2
Compiler used (example: gcc 2.8.0) : gcc version egcs-2.91.66
(egcs-1.1.2 release)
Please enter a FULL description of your problem:
There is a bug when inserting binary values (non-ASCII) in a bytea field,
the escape method ("\\134") doesn't work as expected.
(maybe it is not a bug)
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
Here is the script :
CREATE TABLE az( a bytea);
INSERT INTO az VALUES('\\145');
The SELECT gives 'e' which is correct as ASCII 'e' = '\145' (0x65) .
Now the problem.
With the following :
INSERT INTO az VALUES('\\002');
The SELECT gives the following result : '\002', i.e. four characters,
and not one byte with value of "2". The length of four has been checked
using JDBC.
With the following :
INSERT INTO az VALUES('\\134');
The SELECT gives the following result : '\\', i.e. a double backslash
instead of a single one.
Is this normal ?
Am I supposed to get binary values as escaped ASCII, in order to do a
"sprintf(myvar, sql_result)" to get the real data in myvar ?
If you know how this problem might be fixed, list the solution below:
-
Not known.
--
Olivier Jeannet - e-Payment solutions
I prefer not running 32 bit extensions for a 16 bit patch to an 8 bit
operating system originally coded for a 4 bit microprocessor, written
by a 2 bit company, that can't stand 1 bit of competition.
Re: [BUGS] inserting binary in a bytea field
Olivier Jeannet <[EMAIL PROTECTED]> writes: > Is this normal ? > Am I supposed to get binary values as escaped ASCII, Yes. Otherwise you'd have big trouble with, for example, \000. You can use a binary cursor to read out unconverted data, but that might be more trouble than it's worth. There has been talk of designing some access functions similar to the large-object functionality (lo_read/lo_write, etc) for bytea values. That would bypass this issue and also allow reading/writing large values in sections, which'd be awfully nice. Not done yet though. regards, tom lane
