From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Perl DBI and placeheld values |
Date: | 2003-01-30 07:17:05 |
Message-ID: | 5.1.0.14.1.20030130150909.02f085a0@mbox.jaring.my |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 10:30 PM 1/29/03 +0000, Nigel J. Andrews wrote:
>psql> create table mytab ( thetime timestamptz );
>
>perl:
> $sth = $dbh->prepare('insert into mytab values ( ? )');
> $sth->execute($thetime);
>
>where $thetime could hold 2003-01-29 13:45:06+00 _or_ current_timestamp.
>So just how do others manage this situation without resorting to special
>casing
>everything?
I use 'now' instead of current_timestamp. Despite current_timestamp being
the SQL standard, I figure 'now' is the way to go. Based on recent posts I
gather that the developers have no plans to break that, so it'll be fine to
use it.
Naturally it doesn't work if the field type is text.
Loosely looking for current_timestamp and then not filtering can be
dangerous in uncontrolled environments. e.g. webapps - users could put
current_timestamp in a cgi parameter followed by not so nice SQL.
I suggest you put the functions and stuff in the main SQL, and leave the
placeholders for the data/variables. That way the changeable stuff gets
quoted, and the static stuff is known to be safe.
Hope this helps,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | Lincoln Yeoh | 2003-01-30 07:38:54 | Re: Website troubles |
Previous Message | Dann Corbit | 2003-01-30 07:16:25 | Re: mass import to table with unique index |