On 10/05/2011 03:58 AM, Amit Khandekar wrote:
On 5 October 2011 12:29, Alex Hunsaker wrote:
Find it attached. [ Note I didn't put the check inside the if (ret ==
utf8_str) as it seemed a bit cleaner (indentation wise) to have it
outside ]
I have no more issues with the patch.
Committed.
On Wed, Nov 2, 2011 at 17:12, Andrew Dunstan wrote:
>>> Considering that the issue appears to have been ignored from
>>> mid-February until early October, I don't see why it should now get to
>>> jump to the head of the queue. Other people may have different
>>> opinions, of course.
>>
>> Added.
On 10/07/2011 12:51 PM, Alex Hunsaker wrote:
On Wed, Oct 5, 2011 at 20:36, Robert Haas wrote:
On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsaker wrote:
On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
wrote:
I have no more issues with the patch
On Wed, Oct 5, 2011 at 20:36, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsaker wrote:
>> On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
>>> On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
>>> wrote:
I have no more issues with the patch.
Thanks!
>>>
>>> I think this
On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsaker wrote:
> On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
>> On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
>> wrote:
>>> I have no more issues with the patch.
>>> Thanks!
>>
>> I think this patch needs to be added to the open CommitFest, with
>> lin
On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
> wrote:
>> I have no more issues with the patch.
>> Thanks!
>
> I think this patch needs to be added to the open CommitFest, with
> links to the reviews, and marked Ready for Committer.
The open co
On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
wrote:
> I have no more issues with the patch.
> Thanks!
I think this patch needs to be added to the open CommitFest, with
links to the reviews, and marked Ready for Committer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On 5 October 2011 12:29, Alex Hunsaker wrote:
> On Wed, Oct 5, 2011 at 00:30, Alex Hunsaker wrote:
>> On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
>> wrote:
>
>>> You mean the final changes in plperl_helpers.h would look like
>>> something like this right? :
>>>
>>> static inline char *
>>> ut
On Wed, Oct 5, 2011 at 00:30, Alex Hunsaker wrote:
> On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
> wrote:
>> You mean the final changes in plperl_helpers.h would look like
>> something like this right? :
>>
>> static inline char *
>> utf_u2e(const char *utf8_str, size_t len)
>> {
>> c
On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
wrote:
> On 4 October 2011 22:57, Alex Hunsaker wrote:
>> On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
>> wrote:
>>> On 4 October 2011 14:04, Alex Hunsaker wrote:
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
wrote:
> WHen GetDatab
On 4 October 2011 22:57, Alex Hunsaker wrote:
> On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
> wrote:
>> On 4 October 2011 14:04, Alex Hunsaker wrote:
>>> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
>>> wrote:
>>>
WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
u
On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
wrote:
> On 4 October 2011 14:04, Alex Hunsaker wrote:
>> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
>> wrote:
>>
>>> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
>>> utf8_str, so pg_verify_mbstr_len() will not get called. [.
On 4 October 2011 14:04, Alex Hunsaker wrote:
> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
> wrote:
>
>> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
>> utf8_str, so pg_verify_mbstr_len() will not get called. That's the
>> reason, pg_verify_mbstr_len() is under the ( ret
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
wrote:
> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
> utf8_str, so pg_verify_mbstr_len() will not get called. That's the
> reason, pg_verify_mbstr_len() is under the ( ret == utf8_str )
> condition.
Consider a latin1 database
On 04.10.2011 08:35, Amit Khandekar wrote:
On 3 October 2011 22:37, Alex Hunsaker wrote:
It might be worth adding a regression test also...
I could not find any basic pl/perl tests in the regression
serial_schedule. I am not sure if we want to add just this scenario
without any basic tests fo
On 3 October 2011 22:37, Alex Hunsaker wrote:
> On Mon, Oct 3, 2011 at 04:20, Amit Khandekar
> wrote:
>
>> Is there a plan to commit this issue? I am still seeing this issue on
>> PG 9.1 STABLE branch. Attached is a small patch that targets only the
>> specific issue in the described testcase :
>
On Mon, Oct 3, 2011 at 04:20, Amit Khandekar
wrote:
> Is there a plan to commit this issue? I am still seeing this issue on
> PG 9.1 STABLE branch. Attached is a small patch that targets only the
> specific issue in the described testcase :
>
> create or replace function zerob() returns text as $
On 12 February 2011 14:48, Alex Hunsaker wrote:
> On Sun, Feb 6, 2011 at 15:31, Andrew Dunstan wrote:
>> Force strings passed to and from plperl to be in UTF8 encoding.
>>
>> String are converted to UTF8 on the way into perl and to the
>> database encoding on the way back. This avoids a number of
On Sun, Feb 6, 2011 at 15:31, Andrew Dunstan wrote:
> Force strings passed to and from plperl to be in UTF8 encoding.
>
> String are converted to UTF8 on the way into perl and to the
> database encoding on the way back. This avoids a number of
> observed anomalies, and ensures Perl a consistent vi
On 02/06/2011 09:13 PM, Alex Hunsaker wrote:
I would have loved to add some regression
tests for some of this (like the example hek2cstr states). Is there
any way to do that?
I can't think of an obvious way. Anyone else?
cheers
ndrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Sun, Feb 6, 2011 at 18:02, Andrew Dunstan wrote:
>
>
>
>
>
> On 02/06/2011 05:31 PM, Andrew Dunstan wrote:
>>
>> Force strings passed to and from plperl to be in UTF8 encoding.
>>
>> String are converted to UTF8 on the way into perl and to the
>> database encoding on the way back. This avoids a
On 02/06/2011 05:31 PM, Andrew Dunstan wrote:
Force strings passed to and from plperl to be in UTF8 encoding.
String are converted to UTF8 on the way into perl and to the
database encoding on the way back. This avoids a number of
observed anomalies, and ensures Perl a consistent view of the
22 matches
Mail list logo
