On Mon, Dec 20, 2010 at 7:02 AM, Michael Morris wrote:
> I'm not opposed to using a bitfield, but it's going to be tricky to do
> because there are two settings that want to be 0. Backwards compatibility
> needs to have the 0 setting both for the function calls and the ini setting.
> However, the
I would go with a maskable enumeration for multiple options support:
Val Constant
0PHP_TAGS_NONE
1PHP_TAGS_LEGACY
2PHP_TAGS_STANDARD
4PHP_TAGS_SHORT
8PHP_TAGS_SCRIPT
16PHP_TAGS_ASP
So that if I want to use mixed tags ( wrote:
> I've been giving some thought to the implica
Add my name to the list of people who prefer more strict than syntactic sugar.
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Nov 19, 2010 at 10:36 PM, Philip Olson wrote:
>
> On Nov 19, 2010, at 6:45 PM, Stanley Sufficool wrote:
>> On Fri, Nov 19, 2010 at 8:14 AM, Daniel Convissor
>> wrote:
>>> On Fri, Nov 19, 2010 at 04:41:48PM +0100, Ferenc Kovacs wrote:
>>>> you c
On Fri, Nov 19, 2010 at 8:14 AM, Daniel Convissor
wrote:
> On Fri, Nov 19, 2010 at 04:41:48PM +0100, Ferenc Kovacs wrote:
>> you can get pwn3d with magic_quotes_gpc = On
>
> That goes without saying. None the less, it will be problematic for PHP
> to disable/remove a "security" feature that some
+1 for removal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-1
I won't be using it. I won't argue on this thread since it is a +/-
vote on the idea of Annotations, not the proposed implementation of
it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2010/11/13 Jérôme Loyet :
> Le 12 novembre 2010 23:57, Jani Taskinen a écrit :
>> I updated the patch:
>>
>> http://pecl.php.net/~jani/patches/multi-sapi.patch
>>
>> Now it will fail if no sapi/binary is selected. And "make install" will now
>> also install them all. :)
>
> it seems to work well.
On Sun, Nov 7, 2010 at 2:33 AM, Lester Caine wrote:
> Stanley Sufficool wrote:
>>
>> On Fri, Nov 5, 2010 at 1:28 AM, Lester Caine wrote:
>>>
>>> Stanley Sufficool wrote:
>>>>>
>>>>> Rule Of Thumb:
>>>>>&
On Fri, Nov 5, 2010 at 1:28 AM, Lester Caine wrote:
> Stanley Sufficool wrote:
>>>
>>> Rule Of Thumb:
>>> > If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
>>> > doesn't belong in the DB.
>>>
On Thu, Nov 4, 2010 at 7:44 PM, Richard Lynch wrote:
> On Thu, November 4, 2010 9:09 pm, Stanley Sufficool wrote:
>> On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch wrote:
>>> On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
>
> I realize as the guy who has to d
On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch wrote:
> On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
>> Before I gut PDO_DBLIB one more time to implement native parameter
>> binding for stored procedures, what are the thoughts on returning the
>> column values
On Wed, Nov 3, 2010 at 8:25 PM, Wez Furlong wrote:
>
> On Nov 3, 2010, at 9:52 PM, Stanley Sufficool wrote:
>
>> Before I gut PDO_DBLIB one more time to implement native parameter
>> binding for stored procedures, what are the thoughts on returning the
>> column valu
Before I gut PDO_DBLIB one more time to implement native parameter
binding for stored procedures, what are the thoughts on returning the
column values from the database as the native PHP type when possible?
Currently everything is returned as a string, incurring overhead for
conversion and creating
After reading a little of this back and forth of annotations,
validation and documentation (oh my). I thought, why not just abstract
the standard types (string, int, bool, etc...) to SPL classes.
This would allow for validation, documentation, casting, and related
functions ( length, substr, etc..
On Sat, Jul 3, 2010 at 1:07 PM, Pierre Joye wrote:
> hi,
>
> On Sat, Jul 3, 2010 at 8:40 PM, Stanley Sufficool
> wrote:
>
>> I would argue that the additional fixes in trunk fix bugs rather than
>> introducing new functionality since they were already in the PDO
>&
On Fri, Jul 2, 2010 at 8:45 AM, Christopher Jones
wrote:
>
>
> On 07/02/2010 07:11 AM, Stanley Sufficool wrote:
>>
>> Can I get an affirmation if the pdo dblib code will be accepted in 5.2
>> and 5.3 branches?
>>
>
> It shouldn't go into 5.2 if i
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I have several tests to submit for ext/pdo_dblib.
I have karma to submit patches for ext/pdo_dblib, do I need a blessing
to submit ext/pdo_dblib/tests tests to trunk?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Jun 14, 2010 at 2:21 AM, Ferenc Kovacs wrote:
>> > I don't know sqlite or IBM, but the MySQL SELECT INTO OUTFILE is a plain
>> > SQL
>> > statement, you don't need any special pdo function to use it, on the
>> > other
>> > hand, you can't use the postgresql's COPY TO/FROM with PDO without
On Sun, Jun 13, 2010 at 8:38 PM, Stanley Sufficool wrote:
> On Sun, Jun 13, 2010 at 3:52 PM, Jared Williams
> wrote:
>>
>>
>>> -Original Message-
>>> From: Stanley Sufficool [mailto:ssuffic...@gmail.com]
>>> Sent: 13 June 2010 20:10
>&g
On Sun, Jun 13, 2010 at 3:52 PM, Jared Williams
wrote:
>
>
>> -Original Message-----
>> From: Stanley Sufficool [mailto:ssuffic...@gmail.com]
>> Sent: 13 June 2010 20:10
>> To: Ilia Alshanetsky
>> Cc: Pierre Joye; Denis Gasparin; Matteo Beccati;
>> i
On Sat, Jun 12, 2010 at 4:54 AM, Ilia Alshanetsky wrote:
> The concerns you raised about custom methods specific to database drivers
> were not reflective of the PDO's intent as was clarified by Wez and myself.
>
> The code that was introduced was specific to PostgreSQL, the common
> functionality
On Tue, May 25, 2010 at 6:37 PM, Wez Furlong wrote:
> On Mon, May 24, 2010 at 3:07 PM, Pierre Joye wrote:
>> On Mon, May 24, 2010 at 8:56 PM, Ilia Alshanetsky wrote:
>>> Pierre,
>>> As one of the original authors of PDO that is news to me. PDO was designed
>>> to allow common functionality to be
Maintaining the PDO DBLIB driver and creating new PDO drivers.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, May 11, 2010 at 7:56 PM, Stanislav Malyshev wrote:
> Hi!
>
>> The rest of PHP5 is in English, why do I have to strain my brain or
>> fire up my browser to decipher "Unexpected token
>> T_PAAMAYIM_NEKUDOTAYIM on line ## in". How many native
>> Hebrew speaking programmers will be put off by
for DBLIB, maybe other drivers later.
http://bugs.php.net/bug.php?id=50755
2010/5/14 Johannes Schlüter :
> On Thu, 2010-05-13 at 19:33 -0700, Stanley Sufficool wrote:
>> I would like to contribute to the PDO abstraction layer.
>
> Work on PDO is appreciated. But we don't hand
I would like to contribute to the PDO abstraction layer.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
PDO DBLIB fetch on demand patch revised and posted at:
http://bugs.php.net/bug.php?id=50755&edit=2
Comments are eagerly awaited. I'm excited about this one... I can feel
the warm patch acceptance. ;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.n
On Fri, Mar 19, 2010 at 9:07 AM, Matteo Beccati wrote:
>
> So, I tried to make some time and looked at the patch for 5.3. I have to say
> that I haven't tested it nor I'm an expert by any means of the
> sybase/mysql/freetds api.
>
> Here are my findings:
>
> 1. dblib_driver.c and the README were c
On Mon, Mar 15, 2010 at 8:45 AM, Christopher Jones
wrote:
>
>
> Stanley Sufficool wrote:
>> I have attached patches for bug # 50755 on bugs.php.net. These also
>> cleanup to PDO DBLIB code to have less of a memory footprint and to
>> prepare for other feature additi
I have attached patches for bug # 50755 on bugs.php.net. These also
cleanup to PDO DBLIB code to have less of a memory footprint and to
prepare for other feature additions such as multiple rowset support.
I have compiled and tested on x86.
Can someone review and provide feedback. Thank you.
--
I have attached patches for bug # 50755 on bugs.php.net. These also
cleanup to PDO DBLIB code to have less of a memory footprint and to
prepare for other feature additions such as multiple rowset support.
I have compiled and tested on x86.
Can someone review and provide feedback. PDO devs seem to
On Thu, Jan 21, 2010 at 8:32 PM, Niel Archer wrote:
>> > Stanley Sufficool wrote:
>> > > I have tried to contact the maintainers of PDO with this, but have yet
>> > > to get a response. Can I get this reviewed and if possible commited?
>> > >
>>
I have tried to contact the maintainers of PDO with this, but have yet
to get a response. Can I get this reviewed and if possible commited?
Fixes BUG # 50755:
http://bugs.php.net/bug.php?id=50755&edit=1
Compiled and tested with PHP SVN 5.2
Index: ext/pdo_dblib/dblib_stmt.c
===
35 matches
Mail list logo
