Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] JDBC date problem

From: Aleksey Demakov <avd(at)gcom(dot)ru>
To: Peter T Mount <peter(at)retep(dot)org(dot)uk>
Cc: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] JDBC date problem
Date: 1998-10-19 08:13:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
Peter T Mount <peter(at)retep(dot)org(dot)uk> writes:
> > That is, if the column to contain the row creation date is of type
> > DATETIME, just use now() instead of a ? and a setDate.
> > 
> > INSERT INTO my_table
> >   (creation, other_field1, other_field2, other_field3)
> >   ('now', ?, ?, ?);
> > 
> > Personally, I do this by defining the creation column as a NOT NULL and
> > giving it a default (There's a bit of a trick here, because you have to use
> > a function, or 'now' will be interpreted as the time of the creation of the
> > table, so I define an SQL function which returns 'now'::DATETIME). This
> > enables me to use a statement like
> > 
> > INSERT INTO my_table
> >   (other_field1, other_field2, other_field3)
> >   (?,?,?);
> > 
> > And not bother myself about the creation dates (which are automatic).
> This is a valid point, and for his case, I'd agree with you.

Indeed, in my case this is much better solution. Many thanks to Herouth.

> The Date problem is going to be with us as long as people are still using
> pre 1.1.6 JDK's.

Not quite. Also as long as people are using post 1.1.6 JDK's with the
6.3.2 driver.

> I did think of making the driver sence if the bug is present, and then to
> account for it, but decided against it, on the grounds of performance.

As for me it's ok.

Aleksey Demakov

In response to


pgsql-interfaces by date

Next:From: Byron NikolaidisDate: 1998-10-19 15:26:31
Subject: [Fwd: errors in psqlodbc]
Previous:From: Peter T MountDate: 1998-10-19 05:44:13
Subject: Re: [INTERFACES] JDBC date problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group