Hi Levi,
thanks for your reply.
>> after quite some some I've been finally able to put my hands again on
>> PDO. I know the timing is not ideal, but I hope it's not too late for
>> adding a couple more features and fixes into 5.5.
>
> Purely bug fixes are probably welcome for PHP 5.5 but new fea
> Hi,
>
> after quite some some I've been finally able to put my hands again on
> PDO. I know the timing is not ideal, but I hope it's not too late for
> adding a couple more features and fixes into 5.5.
>
Purely bug fixes are probably welcome for PHP 5.5 but new features are not
welcome at this s
This request was given a +1 from Wez - does anyone else want to provide
feedback? If not, can we get it merged to trunk and queued for release?
On Wed, Oct 3, 2012 at 2:02 PM, Will Fitch wrote:
> Going to bump this thread.
>
> https://bugs.php.net/bug.php?id=62593
> https://github.com/php/php-sr
Going to bump this thread.
https://bugs.php.net/bug.php?id=62593
https://github.com/php/php-src/pull/198
The pull request hasn't had feedback in over a week, and I'd like to make
some progress as this is preventing some from moving to 5.3/5.4.
On Fri, Sep 21, 2012 at 10:52 AM, Wez Furlong wrote
I'll make a point of reviewing this over the weekend; thanks!
--Wez.
On Thu, Sep 20, 2012 at 10:09 AM, Will Fitch wrote:
> Thanks, Pierre - The PR can be found at
> https://github.com/php/php-src/pull/198
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://ww
Thanks, Pierre - The PR can be found at
https://github.com/php/php-src/pull/198
On Tue, Sep 18, 2012 at 3:56 AM, Pierre Joye wrote:
> hi Will,
>
> On Mon, Sep 17, 2012 at 7:45 PM, Will Fitch wrote:
>
> > While I've spent the better part of a week trying to determine the best
> > solution, I wa
hi Will,
On Mon, Sep 17, 2012 at 7:45 PM, Will Fitch wrote:
> While I've spent the better part of a week trying to determine the best
> solution, I want to run this by Ilia, Wez and/or Edin for input. Anyone
> else on the list is also encouraged to provide feedback as well.
Thanks for your det
SELECT '?', ? from "?" where ? = $_$?$_$;
Oracle has bound variables, but you can't use a bind variable for a
table or field in the sql statement.
And I'm not using them for pgsql in the statement above.
My point was that the parser should ignore '?', "?" and $_$?$_$ which
are the three ways of q
On Wed, 23 Mar 2005 09:01:09 +0800, Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
> Hi Dan,
>
> What I mean is, will PDO happily parse this PostgreSQL statement and
> substitute the two variables correctly?
>
> SELECT '?', ? from "?" where ? = $_$?$_$;
Oracle has bound variables, but you ca
> So you are proposing that we rewrite :name and ? params into $n format
> and use pgsql's native prepare/bind functions to do the binding?
Yes.
> BTW, isn't the current sql parser broken for mysql backquoting anyway?
>
> eg: SELECT * FROM `my_weird ? table`;
>
> And in case you're wondering,
Wez Furlong wrote:
The problem with using $ in the query is that you'd need to \ escape
them; remember that PHP uses $ to interpolate its own variables.
IMO, adding $ as another way to name parameters is overkill, as we
already have :named style.
So you are proposing that we rewrite :name and ? pa
The problem with using $ in the query is that you'd need to \ escape
them; remember that PHP uses $ to interpolate its own variables.
IMO, adding $ as another way to name parameters is overkill, as we
already have :named style.
--Wez.
On Wed, 23 Mar 2005 11:33:34 +0800, Christopher Kings-Lynne
Depends on how you define "correctly" ;-)
Chances are that it will raise an error.
I'm not sure if this should really be considered a problem; that's a
really obtuse SQL statement. As a non-pgsqler, I have a hard time
figuring out where the variables are.
Well, anything that's not perfect is a pro
Depends on how you define "correctly" ;-)
Chances are that it will raise an error.
I'm not sure if this should really be considered a problem; that's a
really obtuse SQL statement. As a non-pgsqler, I have a hard time
figuring out where the variables are.
I welcome native postgres prepare/bind/e
Anything beyond this would be an extension to the PDO spec that would
have to be implemented within the actual pdo_pgsql driver.
Also, I guess any extension to PDO would be silly, as it defeats he
point of a standard interface...
Chris
--
PHP Internals - PHP Runtime Development Mailing List
To un
Hi Dan,
What I mean is, will PDO happily parse this PostgreSQL statement and
substitute the two variables correctly?
SELECT '?', ? from "?" where ? = $_$?$_$;
Chris
Dan Scott wrote:
Hi Chris:
As documented in http://www.php.net/manual/en/function.pdo-prepare.php:
"The SQL statement can contain ze
Hi Chris:
As documented in http://www.php.net/manual/en/function.pdo-prepare.php:
"The SQL statement can contain zero or more named (:name) or question
mark (?) parameter markers for which real values will be substituted
when the statement is executed."
Anything beyond this would be an extension
Most of the PDO interface is supported in pgsql driver. However we do not
use native pgsql prepare/execute but PDO's built in emulation for it. If you
could look into how could native api be used in pdo_pgsql that would be
great.
Ooer. How on earth do you simulate the parameter markers? Are they
Hi,
Most of the PDO interface is supported in pgsql driver. However we do not
use native pgsql prepare/execute but PDO's built in emulation for it. If you
could look into how could native api be used in pdo_pgsql that would be
great.
Btw. now you have the commit access to the module.
Edin
-
19 matches
Mail list logo
