#34233 [Fbk->Opn]: PDO ignores parameters when surrounded by closed quotes
ID: 34233
User updated by: php at sagi dot org
Reported By: php at sagi dot org
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.0RC1
Assigned To: wez
New Comment:
Problem still exists with php5-200509020830, pgsql driver.
Did not test with any other driver.
Previous Comments:
[2005-09-01 15:15:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
This works for me in current PHP_5_1 branch using SQLite.
[2005-08-24 13:23:57] php at sagi dot org
Description:
Running PHP5.1.0RC1, postgresql 8 server with v7.4.7 client libs
(pretty sure native prepared statements are disabled).
When trying to execute this query:
$stmt = $db->prepare("SELECT ('0' || :param || '0')");
$stmt->execute(array(':param' => 123));
PDO actually executes this SQL statement: SELECT ('0' || :param ||
'0'), without replacing :param.
It seems like the parser thinks the whole "0' || :param || '0" part is
quoted, though its not.
The query "SELECT (0 || :param || 0)" works as expected.
--
Edit this bug report at http://bugs.php.net/?id=34233&edit=1
#34333 [Fbk->Csd]: PHP5.1 crash / immediate exit
ID: 34333
User updated by: php at sagi dot org
Reported By: php at sagi dot org
-Status: Feedback
+Status: Closed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5CVS-2005-09-01 (CVS)
New Comment:
Works with php5-200509020830, even with full configuration.
Previous Comments:
[2005-09-02 00:23:13] [EMAIL PROTECTED]
Can not reproduce. Try with latest CVS as of now and use this configure
line:
# ./configure --disable-all \
--prefix=/usr/local/php5 \
--with-apxs2=/usr/bin/apxs2
And make sure you don't have multiple LoadModule lines or disabled such
in your httpd.conf.
And if "php -v" doesn't seem to work, try "php -n -v"
--------
[2005-09-01 19:42:57] php at sagi dot org
Description:
I'm trying to run the latest snapshot, php5-200509011630, on i686
machine running debian sarge, apache2 sapi.
It compiles without any problem, but 'make install' fails with the
following:
Installing PEAR environment: /usr/local/php5/share/pear/
make[1]: *** [install-pear-installer] Error 1
make: *** [install-pear] Error 2
It seems like the CLI bin and the apache2 module were installed, but
when running php -v, the program just exists (no crash):
[EMAIL PROTECTED]:~# /usr/local/php5/bin/php -v
[EMAIL PROTECTED]:~#
GDB output:
(gdb) run
Starting program: /usr/local/php5/bin/php
[Thread debugging using libthread_db enabled]
[New Thread 1076854912 (LWP 1377)]
Program exited with code 01.
(gdb)
Strace:
http://beep.boom.org.il/~sagi/bugs/php5_200509011630_strace.txt
When running as apache2 module, it crashes immediately when getting the
first PHP request. Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1079532448 (LWP 1394)]
0x40884031 in php_handler (r=0x81ce510) at
/usr/local/src/php5-200509011630/sapi/apache2handler/sapi_apache2.c:496
496 if (!AP2(engine)) {
(gdb) bt
#0 0x40884031 in php_handler (r=0x81ce510) at
/usr/local/src/php5-200509011630/sapi/apache2handler/sapi_apache2.c:496
#1 0x080783a5 in ap_run_handler ()
#2 0x080789b0 in ap_invoke_handler ()
#3 0x08069c9a in ap_process_request ()
#4 0x0806512d in _start ()
#5 0x081ce510 in ?? ()
#6 0x0004 in ?? ()
#7 0x081ce510 in ?? ()
#8 0x0808373c in ap_run_pre_connection ()
#9 0x080835f5 in ap_run_process_connection ()
#10 0x080769a4 in ap_graceful_stop_signalled ()
#11 0x08076bbb in ap_graceful_stop_signalled ()
#12 0x08076c18 in ap_graceful_stop_signalled ()
#13 0x0807748a in ap_mpm_run ()
#14 0x0807dabd in main ()
(gdb)
PHP was configured with the following parameters:
./configure \
--prefix=/usr/local/php5 \
--with-apxs2=/usr/bin/apxs2 \
--with-zlib \
--with-mysql=shared \
--with-pgsql=shared \
--with-sqlite=shared \
--with-pdo=shared \
--with-pdo-pgsql=shared \
--with-pdo-mysql=shared \
--with-pdo-sqlite=shared \
--with-pear=/usr/local/php5/share/pear \
--with-xmlrpc \
--enable-soap \
--with-gettext=shared \
--with-gd=shared \
--with-jpeg-dir=shared,/usr \
--with-xsl=shared \
--enable-memory-limit
php-5.1.0RC1 works without any problems with the very same
configuration on the same machine.
--
Edit this bug report at http://bugs.php.net/?id=34333&edit=1
#34333 [NEW]: PHP5.1 crash / immediate exit
From: php at sagi dot org
Operating system: Linux
PHP version: 5CVS-2005-09-01 (CVS)
PHP Bug Type: Reproducible crash
Bug description: PHP5.1 crash / immediate exit
Description:
I'm trying to run the latest snapshot, php5-200509011630, on i686 machine
running debian sarge, apache2 sapi.
It compiles without any problem, but 'make install' fails with the
following:
Installing PEAR environment: /usr/local/php5/share/pear/
make[1]: *** [install-pear-installer] Error 1
make: *** [install-pear] Error 2
It seems like the CLI bin and the apache2 module were installed, but when
running php -v, the program just exists (no crash):
[EMAIL PROTECTED]:~# /usr/local/php5/bin/php -v
[EMAIL PROTECTED]:~#
GDB output:
(gdb) run
Starting program: /usr/local/php5/bin/php
[Thread debugging using libthread_db enabled]
[New Thread 1076854912 (LWP 1377)]
Program exited with code 01.
(gdb)
Strace: http://beep.boom.org.il/~sagi/bugs/php5_200509011630_strace.txt
When running as apache2 module, it crashes immediately when getting the
first PHP request. Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1079532448 (LWP 1394)]
0x40884031 in php_handler (r=0x81ce510) at
/usr/local/src/php5-200509011630/sapi/apache2handler/sapi_apache2.c:496
496 if (!AP2(engine)) {
(gdb) bt
#0 0x40884031 in php_handler (r=0x81ce510) at
/usr/local/src/php5-200509011630/sapi/apache2handler/sapi_apache2.c:496
#1 0x080783a5 in ap_run_handler ()
#2 0x080789b0 in ap_invoke_handler ()
#3 0x08069c9a in ap_process_request ()
#4 0x0806512d in _start ()
#5 0x081ce510 in ?? ()
#6 0x0004 in ?? ()
#7 0x081ce510 in ?? ()
#8 0x0808373c in ap_run_pre_connection ()
#9 0x080835f5 in ap_run_process_connection ()
#10 0x080769a4 in ap_graceful_stop_signalled ()
#11 0x08076bbb in ap_graceful_stop_signalled ()
#12 0x08076c18 in ap_graceful_stop_signalled ()
#13 0x0807748a in ap_mpm_run ()
#14 0x0807dabd in main ()
(gdb)
PHP was configured with the following parameters:
./configure \
--prefix=/usr/local/php5 \
--with-apxs2=/usr/bin/apxs2 \
--with-zlib \
--with-mysql=shared \
--with-pgsql=shared \
--with-sqlite=shared \
--with-pdo=shared \
--with-pdo-pgsql=shared \
--with-pdo-mysql=shared \
--with-pdo-sqlite=shared \
--with-pear=/usr/local/php5/share/pear \
--with-xmlrpc \
--enable-soap \
--with-gettext=shared \
--with-gd=shared \
--with-jpeg-dir=shared,/usr \
--with-xsl=shared \
--enable-memory-limit
php-5.1.0RC1 works without any problems with the very same configuration
on the same machine.
--
Edit bug report at http://bugs.php.net/?id=34333&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34333&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34333&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34333&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34333&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34333&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34333&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34333&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34333&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34333&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34333&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34333&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34333&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34333&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34333&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34333&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34333&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34333&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34333&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34333&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34333&r=mysqlcfg
#34233 [Opn]: PDO ignores parameters when surrounded by closed quotes
ID: 34233
User updated by: php at sagi dot org
-Summary: PDO misquotes/miscasts bool(false)
Reported By: php at sagi dot org
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.0RC1
New Comment:
Fixing subject, the bug system somehow changed it to a subject of a
previous bug that I've reported.
Previous Comments:
[2005-08-24 13:23:57] php at sagi dot org
Description:
Running PHP5.1.0RC1, postgresql 8 server with v7.4.7 client libs
(pretty sure native prepared statements are disabled).
When trying to execute this query:
$stmt = $db->prepare("SELECT ('0' || :param || '0')");
$stmt->execute(array(':param' => 123));
PDO actually executes this SQL statement: SELECT ('0' || :param ||
'0'), without replacing :param.
It seems like the parser thinks the whole "0' || :param || '0" part is
quoted, though its not.
The query "SELECT (0 || :param || 0)" works as expected.
--
Edit this bug report at http://bugs.php.net/?id=34233&edit=1
#34233 [NEW]: PDO misquotes/miscasts bool(false)
From: php at sagi dot org
Operating system: Linux
PHP version: 5.1.0RC1
PHP Bug Type: PDO related
Bug description: PDO misquotes/miscasts bool(false)
Description:
Running PHP5.1.0RC1, postgresql 8 server with v7.4.7 client libs (pretty
sure native prepared statements are disabled).
When trying to execute this query:
$stmt = $db->prepare("SELECT ('0' || :param || '0')");
$stmt->execute(array(':param' => 123));
PDO actually executes this SQL statement: SELECT ('0' || :param || '0'),
without replacing :param.
It seems like the parser thinks the whole "0' || :param || '0" part is
quoted, though its not.
The query "SELECT (0 || :param || 0)" works as expected.
--
Edit bug report at http://bugs.php.net/?id=34233&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34233&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34233&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34233&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34233&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34233&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34233&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34233&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34233&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34233&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34233&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34233&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34233&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34233&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34233&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34233&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34233&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34233&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34233&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34233&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34233&r=mysqlcfg
#33876 [Opn]: PDO misquotes/miscasts bool(false)
ID: 33876
User updated by: php at sagi dot org
Reported By: php at sagi dot org
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
For what it's worth, its seems like the pgsql _client_ library that my
installation is compiled against is v7.4.7, even though the server is
running v8.0.
So I guess it never used native prepared statements and the workaround
that you suggested had no affect - they're already disabled.
Previous Comments:
[2005-07-27 16:40:54] php at sagi dot org
Nope, still get the same exception and the same query is being executed
according to the server log.
Still using the same php5-200507261230 snapshot.
The exact code:
$res = $db->prepare(
'SELECT id,name,trial FROM shops WHERE trial = ?',
array(PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT =>
true)
);
$res->execute(array(false));
And the result:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for type boolean: ""' in /home/shopy/dev/tmp/test.php:12
Stack trace:
#0 /home/shopy/dev/tmp/test.php(12): PDOStatement->execute(Array)
#1 {main}
thrown in /home/shopy/dev/tmp/test.php on line 12
[2005-07-27 16:25:22] [EMAIL PROTECTED]
Try this as a workaround for now:
$res = $db->prepare('SELECT ...', array(
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT => true
));
You can blame the pretty poor native prepared statement API in pgsql
for this one; it just doesn't tell PDO anything about the parameter
types so it can't make an informed decision about how to treat the
parameters.
----------------
[2005-07-27 15:56:26] php at sagi dot org
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33876 [Fbk->Opn]: PDO misquotes/miscasts bool(false)
ID: 33876
User updated by: php at sagi dot org
Reported By: php at sagi dot org
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
Nope, still get the same exception and the same query is being executed
according to the server log.
Still using the same php5-200507261230 snapshot.
The exact code:
$res = $db->prepare(
'SELECT id,name,trial FROM shops WHERE trial = ?',
array(PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT =>
true)
);
$res->execute(array(false));
And the result:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for type boolean: ""' in /home/shopy/dev/tmp/test.php:12
Stack trace:
#0 /home/shopy/dev/tmp/test.php(12): PDOStatement->execute(Array)
#1 {main}
thrown in /home/shopy/dev/tmp/test.php on line 12
Previous Comments:
[2005-07-27 16:25:22] [EMAIL PROTECTED]
Try this as a workaround for now:
$res = $db->prepare('SELECT ...', array(
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT => true
));
You can blame the pretty poor native prepared statement API in pgsql
for this one; it just doesn't tell PDO anything about the parameter
types so it can't make an informed decision about how to treat the
parameters.
--------------------
[2005-07-27 15:56:26] php at sagi dot org
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
----
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33876 [Bgs->Opn]: PDO misquotes/miscasts bool(false)
ID: 33876
User updated by: php at sagi dot org
Reported By: php at sagi dot org
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
New Comment:
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
Previous Comments:
[2005-07-27 15:16:02] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
--------
[2005-07-27 00:14:50] php at sagi dot org
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to
pgsql 8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text
representation: 7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is:
"SELECT id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33876 [NEW]: PDO misquotes/miscasts bool(false)
From: php at sagi dot org
Operating system: Linux
PHP version: 5CVS-2005-07-27 (dev)
PHP Bug Type: PDO related
Bug description: PDO misquotes/miscasts bool(false)
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to pgsql
8.0 server.
I'm trying to run a query similar to this:
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text representation:
7 ERROR: invalid input syntax for type boolean: ""'
The query that has been executed, according to the server log, is: "SELECT
id FROM table WHERE mybool = ''"
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit bug report at http://bugs.php.net/?id=33876&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33876&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33876&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33876&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33876&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33876&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33876&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33876&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33876&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33876&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33876&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33876&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33876&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33876&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33876&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33876&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33876&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33876&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33876&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33876&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33876&r=mysqlcfg
#33736 [Fbk->Csd]: PDO confuses pgsql cast operator with named parameter
ID: 33736 User updated by: php at sagi dot org Reported By: php at sagi dot org -Status: Feedback +Status: Closed Bug Type: PDO related Operating System: Linux PHP Version: 5.1.0b2 New Comment: Seems fine after some basic testing, thanks. Previous Comments: [2005-07-18 16:47:58] [EMAIL PROTECTED] Please try the snap dated *after* this message. [2005-07-18 16:47:20] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-17 20:04:17] php at sagi dot org Description: I'm trying to execute a query similar to this: INSERT INTO table (name, created_at) VALUES (:name, FROM_UNIXTIME(:created_at)::TIMESTAMP); On postgres7.4. FROM_UNIXTIME is a custom function, I try to cast its value to TIMESTAMP using the '::' operator. However, PDO thinks ':TIMESTAMP' is a name of another parameter, so it throws this exception: 'SQLSTATE[HY093]: Invalid parameter number: parameter was not defined' Perhaps PDO should not treat '::' as a parameter or at least provide a way to escape ':'. -- Edit this bug report at http://bugs.php.net/?id=33736&edit=1
#33736 [NEW]: PDO confuses pgsql cast operator with named parameter
From: php at sagi dot org Operating system: Linux PHP version: 5.1.0b2 PHP Bug Type: PDO related Bug description: PDO confuses pgsql cast operator with named parameter Description: I'm trying to execute a query similar to this: INSERT INTO table (name, created_at) VALUES (:name, FROM_UNIXTIME(:created_at)::TIMESTAMP); On postgres7.4. FROM_UNIXTIME is a custom function, I try to cast its value to TIMESTAMP using the '::' operator. However, PDO thinks ':TIMESTAMP' is a name of another parameter, so it throws this exception: 'SQLSTATE[HY093]: Invalid parameter number: parameter was not defined' Perhaps PDO should not treat '::' as a parameter or at least provide a way to escape ':'. -- Edit bug report at http://bugs.php.net/?id=33736&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33736&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33736&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33736&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33736&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33736&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33736&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33736&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33736&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33736&r=support Expected behavior: http://bugs.php.net/fix.php?id=33736&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33736&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33736&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33736&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33736&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33736&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33736&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33736&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33736&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33736&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33736&r=mysqlcfg
