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
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
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:
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
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
--- 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
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.
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
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
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
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,
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
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
-
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
14 matches
Mail list logo