On Thu, Nov 21, 2002 at 03:54:56PM -0500, Rudy Lippan wrote:
> On Thu, 21 Nov 2002, Tim Bunce wrote:
>
> > Or ignore colons that have a digit as the previous character
> > as that would never be a placeholder.
>
> Since DBD::Pg emulates place holders, it is possible to have them after a
> digit.
Possible sure, but place holder values should always be viewed and used
as complete lexical tokens. Being over-clever with 'token concatenation'
by doing things like "SELECT * FROM log_:1" and binding a date like
20021122 as a number to select from table log_20021122 is a bad idea.
(FYI I'm not familiar with PostgresSQL's dialect of SQL.)
> I thought that using the [ as a literal marker might break less existing
> code, for example $d->prepare->("insert into foo (int_date)
> VALUES(200301:1"); Or any such other silly uses.
Such silly uses deserve to be broken and replaced with $d->prepare->("insert into foo (int_date) VALUES(:1)")
or $d->prepare->("insert into foo (int_date) VALUES(200301$foo)")
> And besides the array
> data type will probably be used less than other types.
>
> The best solution might be to treat [] as a literal wrt placeholders, but
> allow [:1 for the [:1] case, which is the only case that would work with
> the existing code. Currently, For [:1:2] preparse would see 2 place holders
Viewing place holder values as complete lexical tokens make that
not a sensible thing to do. And, for the only valid uses of
concatenated placeholders, the same effect could be achieved with
one placeholder and concatenating the values bound to it.
> and for [:1::2] preparse would see a place holder and a cast.
Is "::2" a valid cast that people would actually use in real code?
So far I think I'd just extend my original proposal to say
"Ignore colons that have a digit or colon as the previous character".
Tim.