O Pablo Digonzelli έγραψε στις Dec 20, 2004 :
> hi all,
> Ca anyone send me an example how to update a date datatype?
> for example
> update table set birthdate = "200-01-01" doesnt work.
# update table set birthdate = '2000-01-01';
>
> TIA
> Pablo
>
>
> ---(end of
hi,
can postgres be run on a linux cluster, and if so what are the performance
and other issues - checked archives, but the only info is over a year old
kg
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://
or,
# update table set birthdate = to_date('2000-01-01','-MM-DD');
I'm not sure which is better though I tend to do it this way.
regards
Iain
- Original Message -
From: "Achilleus Mantzios" <[EMAIL PROTECTED]>
To: "Pablo Digonzelli" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tue
Kenneth Gonsalves wrote:
hi, can postgres be run on a linux cluster, and if so what are the
performance and other issues - checked archives, but the only info is
over a year old
PG uses shared memory to communicate between backends. Even if your
clustering technology can handle that, it's unlikely
Hi,
I am converting oracle stored procedures to plpgsql. There are several
of the oracle procedures where a parameter vCommit is passed into the
procedure and:
if vCommit = 1
then
commit;
do_something_commit(vdate);
else
do_something(vdate);
end if;
does this make sense i
I don't think you can do transactions within a procedure in postgres, at least
in version 7.x, which I am most familiar with. Page 579 on the postgres 7.4
manual says:
"Functions and trigger procedures are always executed within a transaction
established by an outer query --- they cannot start
Doug Y a écrit :
I can't figure out an efficient way to do this. Basically I had a
typical 3-tier relationship:
(Employee -> Department -> Division)
However, at some point the need to move employees arose, but instead
of changing the key in the emp table, we now have an over-ride table,
so a his
Hi,
I didn't bother analysing this too deeply, so keep that in mind when you
read my reply ;-)
However the point that set off alarm bells for me was this statement "we now
have an over-ride table".
It seems to me that you shouldn't be over-riding anything, and the emp_dept
table should just be
