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

Perl DBI and placeheld values

From: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: pgsql-general(at)postgresql(dot)org
Subject: Perl DBI and placeheld values
Date: 2003-01-29 22:30:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
First off this is not really postgresql specific but it is driving me nuts.

I thought I was using DBI to avoid the issues involved in constructing a SQL
query string using values held in variables. It turns out I'm not I'm using it
because it let's me write fetchrow_blah instead of some DB specific function
that does the samething, like the nice simple API of Pg that no one likes to
suggest people use.

Anyway, back on to the subject. I'm a little stuck and I'm wondering how people
handle the situation where a variable can contain a value _or_ a function
call. For example:

psql> create table mytab ( thetime timestamptz );

	$sth = $dbh->prepare('insert into mytab values ( ? )');

where $thetime could hold 2003-01-29 13:45:06+00 _or_ current_timestamp.

Obviously these are just going to be normal string scalars in perl and DBI is
just going to stick them in place as constant strings. Indeed it's difficult to
see how it could do otherwise without going to great lengths. Even if it did,
what then would it do if the column type was text? The trouble being is guess
what happens when you do:

insert into mytab values ('current_timestamp');

Yep, it doesn't like trying to insert an incorrect timestamp representation
into a timestamp field.

So just how do others manage this situation without resorting to special casing

Nigel J. Andrews


pgsql-general by date

Next:From: Glen ParkerDate: 2003-01-29 22:47:04
Subject: Dropping column silently kills multi-coumn index (was [ODBC] Error when accessing tables with deleted columns)
Previous:From: Michael CalabreseDate: 2003-01-29 22:19:51
Subject: Re: Error when accessing tables with deleted columns

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