[BUGS] ERROR: invalid input syntax for integer: ""

[Pit M.]

Following query fails in pgAdmin which is OK because the field PLZZ 
contains characters:


select * from "PERSONEN" where (CAST("PERSONEN"."PLZZ" AS INTEGER) >= 
7 );


but if using the same query with a cursor ist works:

START TRANSACTION;

DECLARE c21112234 SCROLL CURSOR FOR select * from "PERSONEN" where 
(CAST("PERSONEN"."PLZZ" AS INTEGER) >= 7;


COMMIT;


Why??
In my opinion this query should also fail with cursors.


I use libpq with PG 8.2.1.
The field PLZZ is of type varchar.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [BUGS] ERROR: invalid input syntax for integer: ""

[Pit M.]

It would have failed if you had run the cursor far enough to fetch one
of the bad rows.

regards, tom lane

The difference is that in one case the query fails and in the other the 
FETCH command fails.



Our problem is that if a query succeeds we use a count(*) of that query 
to display the result count in the status bar of our application - the 
select works but the count(*) fails :-)
When we use this query on MS SQL-Server the query fails directly though 
we also use cursors here. So the SQL-Server somehow checks all the data 
only for the query -> perhaps because we used a server side cursor.


Will there be any improvements with cursors in PG 8.3?

Thanks a lot tom

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[BUGS] Re: BUG #3924: Create Database with another encoding as the encoding from postgres

[Pit M.]

Heikki Linnakangas wrote:

Yes, that's an intentional change. From release notes:
I had the same problem this morning. We provide a sample database with 
LATIN1 encoding (included in our setup). So how can i change my encoding 
to have a database that can be used with PG 8.1; 8.1; 8.2 and 8.3 
without problems and without knowing how the server was installed? What 
is the required encoding as LATIN1 was the encoding we prefered.  We 
don't want to use UNICODE.


Regards

Pit

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings