Re: [BUGS] ecpg -D SYMBOL
On Fri, Jul 23, 2004 at 03:49:30PM +1000, Luke McFarlane wrote: > Although if you are to support INFORMIX or INFORMIX_SE mode in ecpg you > will need limit it to 'SQL' space (for these modes anyway). Didn't know that. Thanks for the info. Patch committed to CVS. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] BUG #1200: VACUUM ANALYZE bug
The following bug has been logged online: Bug reference: 1200 Logged by: André Otero Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Debian Linux on Alpha Description:VACUUM ANALYZE bug Details: Before I run the VACUUM ANALYZE command all query that use JOIN command return the error: ERROR invalid typeLen: 0. However the data of tables are unbroken. Example: create table departaments ( dp-id int, name varchar(30), primary key(dp-id) ); create table requests ( rq-id int, dp-id int references departaments(dp-id), description varchar(30), primary key(dp-id) ); insert into departaments values (1,'Informatica'); insert into departaments values (2,'Recurcos Humanos'); insert into departaments values (3,'Compras'); insert into departaments values (4,'Marketing'); insert into departaments values (5,'Diretoria'); insert into departaments values (6,'Ensino'); insert into requests values (1,1,'nothing'); insert into requests values (2,1,'nothing'); insert into requests values (3,2,'nothing'); insert into requests values (4,3'nothing'); insert into requests values (5,4,'nothing'); insert into requests values (6,4'nothing'); select rq-id,name from requests left join departaments on requests.dp-id = departaments.dp.id; this result in: rq-id | name 1 | Informatica 2 | Informatica 3 | Recursos Humanos 4 | Compras 5 | Marketing 6 | Marketing now execute VACUUM ANALYZE the query dont work... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1200: VACUUM ANALYZE bug
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > Before I run the VACUUM ANALYZE command all query that use JOIN command > return the error: ERROR invalid typeLen: 0. You seem to have a rather badly broken copy of Postgres :-( Does it pass the regression tests? (I'd bet not.) PG 7.4 is known to run on Linux/Alpha, and since the report in the "supported platforms" table is from someone at debian.org, I would imagine that test was specifically on Debian. So it ought to work for you. Perhaps you got a corrupted download, or used a buggy compiler to build it, or some such. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1201: void functions called through jdbc driver return error
The following bug has been logged online:
Bug reference: 1201
Logged by: Jonathan Scott
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux
Description:void functions called through jdbc driver return error
Details:
Hello all,
At work here, we are considering upgrading from 7.3 to 7.4, but we've hit a
bit of a snag. We have functions in our schema that have return void. When
called through the 7.4's JDBC driver, we get the following error:
ERROR: function "fulfill_cctrans_item" in FROM has unsupported return type
Our DB unit tests seem to indicate the function is defined and works
correctly; we just get the error when accessing it through the JDBC driver.
Inside our Java code, we use executeQuery() on a CallableStatement object,
as below:
stmt = con.prepareCall("{ call " + statement + "}");
stmt.executeQuery();
Any more info needed, please feel free to contact me.
Thanks,
Jonathan
---(end of broadcast)---
TIP 8: explain analyze is your friend
[BUGS] casting strings to multidimensional arrays yields strange results
Casting strings to multidimensional arrays yields strange results. In one
case there are discard values and the other a value magically appears.
Trying both of these with the array[] constructor syntax yields the
expected:
ERROR: multidimensional arrays must have array expressions with matching
dimensions
Tested on both 7.4.3 and 7.5dev.
Kris Jurka
jurka=# SELECT '{{1,2},{2,3},{4}}'::int[][];
int4
---
{{1},{2},{4}}
jurka=# SELECT '{{1},{2,3},{4,5}}'::int[][];
int4
-
{{1,0},{2,3},{4,5}}
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] BUG #1201: void functions called through jdbc driver
On Tue, 27 Jul 2004, PostgreSQL Bugs List wrote: > Bug reference: 1201 > Logged by: Jonathan Scott > Email address: [EMAIL PROTECTED] > PostgreSQL version: 7.4 > Description:void functions called through jdbc driver return error > > At work here, we are considering upgrading from 7.3 to 7.4, but we've hit a > bit of a snag. We have functions in our schema that have return void. When > called through the 7.4's JDBC driver, we get the following error: > > ERROR: function "fulfill_cctrans_item" in FROM has unsupported return type > To elaborate more on this problem after it gets past the jdbc driver, what happens is that the function call execution is translated into a SQL statement of the form "SELECT * FROM voidfunc();" This produces a server error message: CREATE OR REPLACE FUNCTION voidfunc() RETURNS void AS 'begin return; end;' LANGUAGE plpgsql; SELECT * FROM voidfunc(); ERROR: function "voidfunc" in FROM has unsupported return type It is unclear why this is disallowed. A plain "SELECT voidfunc();" works. Kris Jurka ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
