On Mon, Jun 24, 2013 at 04:00:00PM +0400, Alexander Law wrote:
> Thanks for your work, your patch is definitely better. I agree that this
> approach much more generic.
Committed.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
On Mon, Jun 24, 2013 at 04:00:00PM +0400, Alexander Law wrote:
> 23.06.2013 20:53, Noah Misch wrote:
>> The attached revision fixes all above points. Would you look it over? The
>> area was painfully light on comments, so I added some. I renamed
>> pgwin32_toUTF16(), which ceases to be a good na
Hello Noah,
Thanks for your work, your patch is definitely better. I agree that this
approach much more generic.
23.06.2013 20:53, Noah Misch wrote:
The attached revision fixes all above points. Would you look it over? The
area was painfully light on comments, so I added some. I renamed
pgw
On Wed, Feb 20, 2013 at 04:00:00PM +0400, Alexander Law wrote:
> 15.02.2013 02:59, Noah Misch wrote:
With your proposed change, the problem will resurface in an actual
SQL_ASCII
database. At the problem's root is write_console()'s assumption that
messages
are in the data
Hello,
15.02.2013 02:59, Noah Misch wrote:
With your proposed change, the problem will resurface in an actual SQL_ASCII
database. At the problem's root is write_console()'s assumption that messages
are in the database encoding. pg_bind_textdomain_codeset() tries to make that
so, but it only wo
On Thu, Feb 14, 2013 at 11:11:13AM +0400, Alexander Law wrote:
> Hello,
> Alexander Law writes:
>> Please look at the following l10n bug:
>> http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
>> and the proposed patch.
>> With your proposed change, the problem will res
On 02/15/2013 12:45 AM, Peter Eisentraut wrote:
> On 2/11/13 10:22 PM, Greg Stark wrote:
>> On Sun, Feb 10, 2013 at 11:47 PM, Tom Lane wrote:
>>> If we knew that postgresql.conf was stored in, say, UTF8, then it would
>>> probably be possible to perform encoding conversion to get string
>>> variab
On 2/11/13 10:22 PM, Greg Stark wrote:
> On Sun, Feb 10, 2013 at 11:47 PM, Tom Lane wrote:
>> If we knew that postgresql.conf was stored in, say, UTF8, then it would
>> probably be possible to perform encoding conversion to get string
>> variables into the database encoding. Perhaps we should all
Hello,
Alexander Law writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
With your proposed change, the problem will resurface in an actual SQL_ASCII
database. At the problem's root is write_console()'s assumpt
On Tue, Feb 12, 2013 at 03:22:17AM +, Greg Stark wrote:
> But that said I'm not sure saying the whole file is in an encoding is
> the right approach. Paths are actually binary strings. any encoding is
> purely for display purposes anyways.
For Unix, yes. On Windows, they're ultimately UTF16 s
On Sun, Feb 10, 2013 at 11:47 PM, Tom Lane wrote:
> If we knew that postgresql.conf was stored in, say, UTF8, then it would
> probably be possible to perform encoding conversion to get string
> variables into the database encoding. Perhaps we should allow some
> magic syntax to tell us the encodi
Noah Misch writes:
> On Sun, Feb 10, 2013 at 06:47:30PM -0500, Tom Lane wrote:
>> The key problem, ISTM, is that it's not at all clear what encoding to
>> expect the incoming data to be in. I'm concerned about trying to fix
>> that by assuming it's in some "platform encoding" --- for one thing,
>
On Sun, Feb 10, 2013 at 06:47:30PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Following some actual testing, I see that we treat postgresql.conf values as
> > byte sequences; any reinterpretation as encoded text happens later. Hence,
> > contrary to my earlier suspicion, your patch does not
Noah Misch writes:
> Following some actual testing, I see that we treat postgresql.conf values as
> byte sequences; any reinterpretation as encoded text happens later. Hence,
> contrary to my earlier suspicion, your patch does not make that situation
> worse. The present situation is bad; among
On Wed, Jan 30, 2013 at 10:00:01AM +0400, Alexander Law wrote:
> 30.01.2013 05:51, Noah Misch wrote:
>> On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
>>> Alexander Law writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.c
30.01.2013 05:51, Noah Misch wrote:
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
That patch looks entirely unsafe to me. Neither o
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
> Alexander Law writes:
> > Please look at the following l10n bug:
> > http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
> > and the proposed patch.
>
> That patch looks entirely unsafe to me. Neither of those functions
> sh
Alexander Law writes:
> Please look at the following l10n bug:
> http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
> and the proposed patch.
That patch looks entirely unsafe to me. Neither of those functions
should be expected to be able to run when none of our standard
infrastruct
Hello,
Thanks for fixing bug #6510!
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
Best regards,
Alexander
>From 1e2d5f712744d4731b665724703c0da4971ea41e Mon Sep 17 00:00:00 2001
From: Alexander Lakhin
Date: Mon, 28
19 matches
Mail list logo
