Re: pl/perl and utf-8 in sql_ascii databases - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: pl/perl and utf-8 in sql_ascii databases
Date
Msg-id 20120622.170128.114047775.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: pl/perl and utf-8 in sql_ascii databases  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Hello.

> > Renaming ret to quoted and str to ret as the patch attached might
> > make it easily readable.
> 
> I think I'm going to refrain from this because it will be more painful
> to backpatch.

I've felt hesitation to do so, too.

The new patch is indeed avoid leaks although which does not lasts
permanently. This will preserve more heap for future work but has
no necessity to do.

On the other hand, the return value of DatumGetTextP() is also
may (and 'should' in this case) palloc'ed but not pfree'd like
other part of PostgreSQL source (as far as I saw..) because of, I
suppose, the nature of these functions that it is
difficult/unable to be predicted/determined whether returning
memory block is palloc'ed ones or not. And the pain to maintain
such codes unrobust for future modification.

From such a point of view, we might be good to refrain to
backport this.


> > The attached ugly patch does it. We seem should put NO_LOCALE=1
> > on the 'make check' command line for the encodings not compatible
> > with the environmental locale, although it looks work.
> 
> The idea of separating the test into its own file has its merit; but
> instead of having two different tests, I'm going to have a single test
> and two expected files.  That seems simpler than messing around in the
> makefile.

Yes, you're right. But it was easier to add pairs of .sql and
.out to do that. Plus, as I wrote in another message, I'm
unwilling to push it nevertheless I've wrote it:-(

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

== My e-mail address has been changed since Apr. 1, 2012.


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Catalog/Metadata consistency during changeset extraction from wal
Next
From: Jeff Davis
Date:
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree