Hi,
these changes are in CVS. Changed a bit though. Since there is no
inputting of timestamps other than CURRENT_TIMESTAMP, I have not used
the TO_DATE string yet, but a function to use it is already in db.c :)
db_insert_physmessage() uses CURRENT_TIMESTAMP.
I've tested with PostgreSQL, and
Oh, oh I got it! In mysql/dbmysql.c and pgsql/pgsql.c we define variable(s):
MySQL:
const char *TO_DATE = "DATE_FORMAT(%s, \"%%Y-%%m-%%d %%H:%%m:%%s\")";
const char *TO_DATE = "DATE_FORMAT(%s, \"%%Y-%%m-%%d %%H:%%m:%%s\")";
PostgreSQL:
const char *TO_DATE = "TO_DATE(%s, \"-MM-DD HH:MI:SS\" )";
Hi,
I was thinking of the best way to solve this problem.
Clearly, in the end, we should not be dependent on the format in which
the database stores the DATE-format. This calls for a solution like the
one that Aaron pointed out (although I'd rather just use to_char()..)
For now, I think we s
Hi,
I agree that we should use some kind of scheme to get a fixed format
from the database. I wonder why to_char() and to_date() are not in
MySQL. They are part of SQL92, aren't they?
Is it possible to include the database functions, from the URL Aaron
provided, in an installation script? If
Using explicit ANSI SQL functions should give us better portability to
whatever default format the database wants to use. I think it's quite bad form
that we're currently assuming that the database will store and return the
format that we want simply because we remembered to use the right column ty
Paul F. De La Cruz wrote:
On Tue, Feb 24, 2004 at 09:16:59PM -, Aaron Stone wrote:
As long as this doesn't cause pre-7.1 version of PostgreSQL to choke, the
change should definitely be made before 2.0rc3!
I think it would make the pre-7.1 versions of PostgreSQL choke as they eithe
On Tue, Feb 24, 2004 at 09:16:59PM -, Aaron Stone wrote:
> "Paul F. De La Cruz" <[EMAIL PROTECTED]> said:
> [huge snip of almost everything]
>
> >internal_date TIMESTAMP WITHOUT TIME ZONE,
>
> As long as this doesn't cause pre-7.1 version of PostgreSQL to choke, the
> change should defini
"Paul F. De La Cruz" <[EMAIL PROTECTED]> said:
[huge snip of almost everything]
>internal_date TIMESTAMP WITHOUT TIME ZONE,
As long as this doesn't cause pre-7.1 version of PostgreSQL to choke, the
change should definitely be made before 2.0rc3!
Also, what about adding more sanity/format che
