Re: [BUGS] Libpq.dll: File not recognized
On Wed, Jun 30, 2010 at 11:23 PM, Bidski wrote: > Hi all, > > I downloaded the "one-click" installer for PostgreSQL 9.0 beta2 for Windows > x64 (postgresql-9.0.0-beta2-windows-x64.exe) and installed it on my Windows > 7 64 bit system. Installation seemed to go off without a hitch, but when I > tried to link to libpq in my project I received the following error. > > > C:\Program Files\PostgreSQL\lib/libpq.dll: file not recognized: File > format not recognized Don't link against the DLL, link against the .lib. > Some system info. > > OS: Windows 7 64-bit > > MSYS ver: 1.0.14 > > MinGW ver: 4.5.0 > > Make ver: GNU make 3.81 > > If it matters . My IDE is Eclipse Galileo and I am compiling my project > using the MinGW toolchain. The server is built with VC++ 2008 - I have no idea if Mingw can use 64bit VC++ libraries. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Libpq.dll: File not recognized
"Dave Page" writes: Don't link against the DLL, link against the .lib. Isnt the .lib the static library and the dll the shared library? And Im not linking against the dll specifically, that is the library that g++ is wanting to link to. My link command is g++ -Wl,--enable-auto-import -o"MRP.exe" ./src/DB.o ./src/catlist.o ./src/inventory.o ./src/mrp_app.o ./src/mrp_frame.o ./res/resources.rc.o -lpq -L"C:\MinGW\lib" -L"C:\Program Files\PostgreSQL\lib" -mwindows `wx-config --libs base,core,adv,xrc` The server is built with VC++ 2008 - I have no idea if Mingw can use 64bit VC++ libraries. I also have no idea for certain, but I should think so. My understanding of the whole thing is that a DLL made for windows should be linkable to any windows application regardless of compiler/linker, if its not then what is the point? Regards Bidski -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Libpq.dll: File not recognized
On Thu, Jul 1, 2010 at 9:00 AM, Bidski wrote: > "Dave Page" writes: >> >> Don't link against the DLL, link against the .lib. > > Isnt the .lib the static library and the dll the shared library? No, it should be the import library for the DLL. > And Im not > linking against the dll specifically, that is the library that g++ is > wanting to link to. My link command is > > g++ -Wl,--enable-auto-import -o"MRP.exe" ./src/DB.o ./src/catlist.o > ./src/inventory.o ./src/mrp_app.o ./src/mrp_frame.o ./res/resources.rc.o > -lpq -L"C:\MinGW\lib" -L"C:\Program Files\PostgreSQL\lib" -mwindows > `wx-config --libs base,core,adv,xrc` That looks right - and should be looking for the .lib (or a .a) as you just have -lpq. Should there be a -m64 in there though? Try compiling a test program and verify that you actually are getting 64 bit output. >> The server is built with VC++ 2008 - I have no idea if Mingw can use >> 64bit VC++ libraries. > > I also have no idea for certain, but I should think so. My understanding of > the whole thing is that a DLL made for windows should be linkable to any > windows application regardless of compiler/linker, if its not then what is > the point? The DLLs should be portable, but the import library might not be. I vaguely recall that VC++ cannot use a Mingw import library - though you can fairly easily create a compatible library from the incompatible one. I don't recall the details though - Google is your friend. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5533: PQexecParams in Binary Mode returns incorrect value for float4
The following bug has been logged online:
Bug reference: 5533
Logged by:
Email address: myk...@gmail.com
PostgreSQL version: 8.4.3
Operating system: Ubuntu 10.04
Description:PQexecParams in Binary Mode returns incorrect value for
float4
Details:
Experience: PQexecParams (pqlib) in binary mode returns incorrect value for
float4 data type.
Example: Code below extracts a 0.75 float4 value from PostgreSQL, but
pqlib's PQexecParams returns 1.812500. Same query in text mode returns 0.75
correctly. Expected 0.75 return value in Binary mode.
Machine:
Dell Precision - Core 2 Duo
Ubuntu 10.04 LTS (Lucid Lynx)
PostgresQL 8.4.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6
20060404 (Red Hat 3.4.6-10), 32-bit
Demo.c starts here
// C Prototypes and Std Include headers
#include
#include
#include
#include
#include "libpq-fe.h"
// Some silly parameters for handling postgreql
#define oidINT4 23;
#define oidFLOAT4 700;
#define TextFormat 0;
#define BinaryFormat 1;
void main()
{
PGconn* conn;
PGresult *res;
//Parameters for the insert
int inParams = 2;
Oid iParamTypes[2];
char* iParamValues[2];
int iParamLengths[2];
int iParamFormats[2];
int iResultFormat = BinaryFormat;
//Parameters for the select
int snParams = 1;
Oid sParamTypes[1];
char* sParamValues[1];
int sParamLengths[1];
int sParamFormats[1];
int sResultFormat = BinaryFormat;
//Index Value
int Index;
//Variables to handle the float4
union
{
float f;
unsigned int i;
} Swap;
char* ptrFltValue;
// Connect to the default database and create a test table consisting
of a
column of int4 and float4
conn = PQconnectdb("dbname=postgres user=postgres password=");
res = PQexec(conn, "CREATE TABLE testtbl( Intgr int4, Flt float8,
PRIMARY
KEY ( Intgr ));");
PQclear(res);
//Insert 1 rows, 1 containing 0.75 the float4 field (100 in the int4
field)
iParamTypes[0] = oidINT4;
iParamTypes[1] = oidFLOAT4;
iParamLengths[0] = sizeof(unsigned int);
iParamLengths[1] = sizeof(float);
iParamFormats[0] = BinaryFormat;
iParamFormats[1] = BinaryFormat;
Index = htonl(100);
iParamValues[0] = (char*) &Index;
Swap.f = 0.75;
Swap.i = htonl(Swap.i);
iParamValues[1] = (char*) &Swap;
res = PQexecParams(conn, "Insert into testtbl(Intgr, Flt) Values ($1,
$2);", inParams, &iParamTypes,
iParamValues, &iParamLengths, &iParamFormats,
iResultFormat);
PQclear(res);
//Retrieve the row in Binary mode
sParamTypes[0] = oidINT4;
sParamLengths[0] = sizeof(unsigned int);
sParamFormats[0] = BinaryFormat;
sParamValues[0] = (char*) &Index;
res = PQexecParams(conn, "SELECT * FROM testtbl where (Intgr = $1);",
snParams, &sParamTypes,
sParamValues, &sParamLengths,
&sParamFormats, sResultFormat);
ptrFltValue = PQgetvalue(res,0,1);
Swap.i = ntohl(*((int *) ptrFltValue));
//Print the Binary mode result
printf("Flt retrieved in Binary mode is = %f.\n", Swap.f);
//Retrieve the row in Text mode
PQclear(res);
sResultFormat = TextFormat;
res = PQexecParams(conn, "SELECT * FROM testtbl where (Intgr = $1);",
snParams, &sParamTypes,
sParamValues, &sParamLengths,
&sParamFormats, sResultFormat);
//Print the Text mode results
printf("Flt retrieved in Binary mode is = %s.\n", PQgetvalue(res,0,1));
//Clean-up
PQclear(res);
PQfinish(conn);
return;
}
Demo.c ends here
Makefile starts here
#
# Makefile for Demo application
# Use by invoking 'make' on the command line
#
# Specify the compiler
CC = gcc
# Specify the pre-processor flags
CPPFLAGS += -I/opt/PostgreSQL/8.4/include
CPPFLAGS += -I${HOME}
# Specify the compiler flags
CFLAGS += -c
CFLAGS += -g
# Specify the linker flags
LDFLAGS += -g
# Specify the linker libraries
LDLIBS += -L/opt/PostgreSQL/8.4/lib -lpq
LDLIBS += /opt/PostgreSQL/8.4/lib/libssl.so.4
LDLIBS += /opt/PostgreSQL/8.4/lib/libcrypto.so.4
# Specify the files making up the application
SOURCES = Demo.c
EXECUTABLE = Demo
all: $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
$(CC) $(LDFLAGS) $(LDLIBS) $(OBJECTS) -o $@
.c.o:
$(CC) $(CPPFLAGS) $(CFLAGS) $< -o $@
install:
@echo "Build complete!"
Makefile ends here
Some needless speculation:
0.75 = 3F40 (as IEEE 32-bit float)
0.75 = 3FE8 (as IEEE 64-bit float)
1.812500 = 3FE8 (as returned by PQexecParams)
i.e. the return value is the first 32-bits of the 64-bit representation of
the correct value.
Same result apparent for 1.22 test value
Returns: 1.902500.
1.22 = 3F9C28F6 (as IEEE 32-bit float)
1.22 = 3FF3851EB851EB85 (as 64-bit IEEE 64-
Re: [BUGS] BUG #5533: PQexecParams in Binary Mode returns incorrect value for float4
"" writes: > Some needless speculation: > 0.75 = 3F40 (as IEEE 32-bit float) > 0.75 = 3FE8 (as IEEE 64-bit float) > 1.812500 = 3FE8 (as returned by PQexecParams) > i.e. the return value is the first 32-bits of the 64-bit representation of > the correct value. Well, yeah. You declared the column as float8, not float4: > res = PQexec(conn, "CREATE TABLE testtbl( Intgr int4, Flt float8, > PRIMARY KEY ( Intgr ));"); regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5534: IS DOCUMENT predicate errors instead of returning false
The following bug has been logged online: Bug reference: 5534 Logged by: Mike Fowler Email address: m...@mlfowler.com PostgreSQL version: 9.0beta2 Operating system: Linux 2.6.31-14-generic #48-Ubuntu SMP Description:IS DOCUMENT predicate errors instead of returning false Details: IS DOCUMENT should return false for a non-well formed document, and indeed is coded to do such. However, the conversion to the xml type which happens before the underlying xml_is_document function is even called fails and exceptions out. I've mentioned this on -hackers with message ID 20100701172553.w5vdy1xbocos8...@www.mlfowler.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5531: REGEXP_ REPLACE causes connection drop
ola sergatchov writes: > Here is the copy from postgresql log from June 23: > ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used > ERROR: out of memory > DETAIL: Failed on request of size 251049. > CONTEXT: PL/pgSQL function "composite_statements_as_set" line 36 at > assignment > SQL function "composite_statements_wrapper" statement 1 > SQL function "dml_statements" statement 1 > LOG: unexpected EOF on client connection This does not indicate any problem in Postgres. The "unexpected EOF" message indicates that the *client* dropped the connection, not that Postgres did. Possibly you need to look at the error processing logic in your application. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5535: Backslash in condition for LIKE statement is not seen
The following bug has been logged online:
Bug reference: 5535
Logged by: Jeff Benjamin
Email address: j...@ivertex.com
PostgreSQL version: 8.3.8
Operating system: MacOSX, Linux
Description:Backslash in condition for LIKE statement is not seen
Details:
Seems one cannot use a backslash character in a LIKE condition.
backslashprob=# create table test ( pattern varchar(50) );
CREATE TABLE
backslashprob=# insert into test (pattern) values ('\\w{12}');
INSERT 0 1
backslashprob=# select * from test;
pattern
-
\w{12}
(1 row)
backslashprob=# select * from test where pattern like '\\w%';
pattern
-
(0 rows)
backslashprob=# select * from test where pattern like E'\\w%';
pattern
-
(0 rows)
backslashprob=# select * from test where pattern like '%w%';
pattern
-
\w{12}
(1 row)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5535: Backslash in condition for LIKE statement is not seen
"Jeff Benjamin" wrote: > Seems one cannot use a backslash character in a LIKE condition. By default that has special meaning as an escape character. Try this: select * from test where pattern like E'\\w%' escape '#'; or this: select * from test where pattern like E'w%'; -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5535: Backslash in condition for LIKE statement is not seen
Thanks, that works! On Jul 1, 2010, at 1:34 PM, Kevin Grittner wrote: > "Jeff Benjamin" wrote: > >> Seems one cannot use a backslash character in a LIKE condition. > > By default that has special meaning as an escape character. > > Try this: > > select * from test where pattern like E'\\w%' escape '#'; > > or this: > > select * from test where pattern like E'w%'; > > -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5531: REGEXP_ REPLACE causes connection drop
Sure. Here is the copy from postgresql log from June 23: ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used ERROR: out of memory DETAIL: Failed on request of size 251049. CONTEXT: PL/pgSQL function "composite_statements_as_set" line 36 at assignment SQL function "composite_statements_wrapper" statement 1 SQL function "dml_statements" statement 1 LOG: unexpected EOF on client connection The 8.1.18 is used in our product and it is embedded in the production environment of our client. We are planning to upgrade to more recent release, but currently it is not possible. Please let me know if you need any more help. > From: br...@momjian.us > Subject: Re: [BUGS] BUG #5531: REGEXP_ REPLACE causes connection drop > To: ola_sergatc...@hotmail.com > Date: Wed, 30 Jun 2010 11:46:53 -0400 > CC: pgsql-bugs@postgresql.org > > Ola Sergatchov wrote: > > > > The following bug has been logged online: > > > > Bug reference: 5531 > > Logged by: Ola Sergatchov > > Email address: ola_sergatc...@hotmail.com > > PostgreSQL version: 8.1.18 > > Operating system: RedHat Linux 4.1.2-46 > > Description: REGEXP_ REPLACE causes connection drop > > Details: > > > > Passing large string to REGEXP_REPLACE function causes the DB connection to > > drop. We executed this function with very large strings (20,000 - 250,000 > > characters) both from RedHat and PgAdmin and in both cases the function > > fails to return and eventually the connection drops. From looking in the > > documentation, there is no reference to the maximum size of the string that > > his function can process. > > Can you show us any relevant entries in the server logs? FYI, 8.1.18 is > both old for minor and major release. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + None of us is going to be here forever. + _ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969
