Hello,
We are thinking of building our own version of Oracle's sysdate, in
the form of PostgreSQL extension.
Consider the behavior of sysdate for multiple inserts inside a function
CREATE OR REPLACE FUNCTION fun2
RETURN number
IS var1 number(10); var2 number (2);
BEGIN
insert into t1 select
On Tue, Aug 19, 2014 at 07:41:00PM +0530, Sameer Thakur wrote:
We are thinking of building our own version of Oracle's sysdate, in
the form of PostgreSQL extension.
I thought that was the point of the statement_timestamp() function?
A
--
Andrew Sullivan
a...@crankycanuck.ca
--
Sent via
On 08/19/2014 07:11 AM, Sameer Thakur wrote:
Hello,
We are thinking of building our own version of Oracle's sysdate, in
the form of PostgreSQL extension.
Consider the behavior of sysdate for multiple inserts inside a function
CREATE OR REPLACE FUNCTION fun2
RETURN number
IS var1
Sameer Thakur samthaku...@gmail.com writes:
We are thinking of building our own version of Oracle's sysdate, in
the form of PostgreSQL extension.
Consider the behavior of sysdate for multiple inserts inside a function
CREATE OR REPLACE FUNCTION fun2
RETURN number
IS var1 number(10);
Hello Tom,
Do you really need to be bug-compatible with Oracle's SYSDATE at that
level of detail?
We did a Oracle to PostgreSQL migration recently, and migrating
sysdate was an issue. Figuring out whether to use clock_timestamp,
timestamp(0), and cases in which both options are incorrect, took