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
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
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 name now
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 database encoding.
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
On 2/11/13 10:22 PM, Greg Stark wrote:
On Sun, Feb 10, 2013 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us 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
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 t...@sss.pgh.pa.us 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
On Thu, Feb 14, 2013 at 11:11:13AM +0400, Alexander Law wrote:
Hello,
Alexander Law exclus...@gmail.com 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
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
Hello,
Alexander Law exclus...@gmail.com 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
On Sun, Feb 10, 2013 at 06:47:30PM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com 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
Noah Misch n...@leadboat.com 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
On Sun, Feb 10, 2013 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us 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
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 exclus...@gmail.com writes:
Please look at the following l10n bug:
Noah Misch n...@leadboat.com 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
Alexander Law exclus...@gmail.com 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
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law exclus...@gmail.com 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
30.01.2013 05:51, Noah Misch wrote:
On Tue, Jan 29, 2013 at 09:54:04AM -0500, Tom Lane wrote:
Alexander Law exclus...@gmail.com 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
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
19 matches
Mail list logo
