Re: [INTERFACES] JDBC date problem
От | Aleksey Demakov |
---|---|
Тема | Re: [INTERFACES] JDBC date problem |
Дата | |
Msg-id | 871zo5dl65.fsf@avd.garsib.ru обсуждение исходный текст |
Ответ на | Re: [INTERFACES] JDBC date problem (Peter T Mount <peter@retep.org.uk>) |
Ответы |
Re: [INTERFACES] JDBC date problem
|
Список | pgsql-interfaces |
Peter T Mount <peter@retep.org.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) > > VALUES > > ('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) > > VALUES > > (?,?,?); > > > > 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 avd@gcom.ru
В списке pgsql-interfaces по дате отправления: