[BUGS] Time intervals in select statement

2004-10-19 Thread Luke McFarlane
Hello Given the following example table: CREATE TABLE foo ( create_time TIMESTAMP WITHOUT TIME ZONE ); INSERT INTO foo (create_time) VALUES (now()); INSERT INTO foo (create_time) VALUES (now()); INSERT INTO foo (create_time) VALUES (now()); This select statement works: SELECT create_time, create_ti

Re: [BUGS] Time intervals in select statement

2004-10-19 Thread Tom Lane
Luke McFarlane <[EMAIL PROTECTED]> writes: > SELECT create_time, create_time - '8 days 16:49:22.600601' FROM foo; > ERROR: invalid input syntax for type timestamp: "8 days 16:49:22.600601" Cast the constant to interval explicitly. regards, tom lane -

Re: [BUGS] Time intervals in select statement

2004-10-19 Thread Luke McFarlane
Tom Yes, that does indeed work. It's interesting why addition assumes one operand is interval while subtraction assumes it is timestamp? It should at least be consistent, IMHO. Cheers Luke Tom Lane wrote: Luke McFarlane <[EMAIL PROTECTED]> writes: SELECT create_time, create_time - '8 days 16:4

Re: [BUGS] Mac OS X make check errors...

2004-10-19 Thread Theodore Petrosky
I only added the --disable-shared from a recommendation on the cocoa developers forum. Someone reported problems using libpq.a and the solution offered was the above. The original person spoke of problems linking libpg.a. The poster mentioned something about even though he specified the libpg.a,

Re: [BUGS] Time intervals in select statement

2004-10-19 Thread Tom Lane
Luke McFarlane <[EMAIL PROTECTED]> writes: > It's interesting why addition assumes one operand is interval while > subtraction assumes it is timestamp? It should at least be consistent, IMHO. There is no timestamp + timestamp operator, for reasons that should be fairly apparent. There are both t

[BUGS] a bug in pg_dump?

2004-10-19 Thread Jaime Casanova
Hi all, I have database with 6 schemas, i did an: alter database set search_path to 'public', 'pg_catalog', 'academico', 'dobe', 'recaudaciones', 'becas', 'roles', 'seguridad' but when i do a: pg_dump -C uescc > uescc.sql it add the create statement for the database but not add appropiates alter

Re: [BUGS] a bug in pg_dump?

2004-10-19 Thread Tom Lane
Jaime Casanova <[EMAIL PROTECTED]> writes: > but when i do a: pg_dump -C uescc > uescc.sql > it add the create statement for the database but not > add appropiates alter database for the parameters i > set search_path in this case. > But, pg_dumpall does. > a bug in pg_dump? No. That functional

Re: [BUGS] a bug in pg_dump?

2004-10-19 Thread Alvaro Herrera
On Tue, Oct 19, 2004 at 02:25:35PM -0400, Tom Lane wrote: > Jaime Casanova <[EMAIL PROTECTED]> writes: > > but when i do a: pg_dump -C uescc > uescc.sql > > it add the create statement for the database but not > > add appropiates alter database for the parameters i > > set search_path in this case.

Re: [BUGS] a bug in pg_dump?

2004-10-19 Thread Jaime Casanova
--- Alvaro Herrera <[EMAIL PROTECTED]> escribió: > On Tue, Oct 19, 2004 at 02:25:35PM -0400, Tom Lane > wrote: > > Jaime Casanova <[EMAIL PROTECTED]> writes: > > > but when i do a: pg_dump -C uescc > uescc.sql > > > it add the create statement for the database but > not > > > add appropiates alte

Re: [BUGS] BUG #1286: indices not used after a pg_restore

2004-10-19 Thread Tom Lane
Federico Di Gregorio <[EMAIL PROTECTED]> writes: > ok. attached to this mail is a dump in tar format. this is the EXPLAIN > ANALYZE of a query *before* the dump: > EXPLAIN ANALYZE SELECT * FROM BOL_USC > WHERE UPPER(RPAD("RAGIONE",80)||TO_CHAR("IDBOL_USC",'S00')) >= > ' +000

[BUGS] bug 1201

2004-10-19 Thread federico
i saw in bug 1201 that some got my problem i detail it i have a function that returns a void CREATE OR REPLACE FUNCTION myFunction(int2, int2) RETURNS void AS $BODY$ UPDATE table SET field1 = $1 WHERE field2 = $2; $BODY$ LANGUAGE 'sql' VOLATILE; when i execute it with a callablestatement Call

Re: [BUGS] bug 1201

2004-10-19 Thread Kris Jurka
On Tue, 19 Oct 2004, federico wrote: > i saw in bug 1201 that some got my problem > [ you can't do "SELECT * FROM func_returning_void();" ] This patch seems to fix it, although I have no idea what the actual implications are, I just changed any place that produced an error. Kris Jurka Index:

Re: [BUGS] bug 1201

2004-10-19 Thread Alvaro Herrera
On Tue, Oct 19, 2004 at 06:23:07PM -0500, Kris Jurka wrote: > > On Tue, 19 Oct 2004, federico wrote: > > > i saw in bug 1201 that some got my problem > > [ you can't do "SELECT * FROM func_returning_void();" ] > > This patch seems to fix it, although I have no idea what the actual > implication

Re: [BUGS] bug 1201

2004-10-19 Thread Kris Jurka
On Tue, 19 Oct 2004, Alvaro Herrera wrote: > Huh, shouldn't the user rather do > > SELECT func_returning_void(); The problem is that the function may actually be a SRF so the JDBC driver transforms to the "SELECT * FROM" form. The JDBC driver doesn't want to get into the business of trying to