On 25 September 2013 12:49, Amit Khandekar
wrote:
>
> 0003-Convert-object-names-to-**archive-encoding-before-matc.**patch
>>
>> Use iconv(3) in pg_restore to do encoding conversion in the client. This
>> involves a lot of autoconf changes that I'm not 100% sure about, other than
>> that it's prett
On 27 August 2013 20:06, Heikki Linnakangas wrote:
> On 26.08.2013 18:59, Tom Lane wrote:
>
>> Heikki Linnakangas>
>> writes:
>>
>> The pg_dump -E option just sets client_encoding, but I think it would be
>>> better for -E to only set the encoding used in the dump, and
>>> PGCLIENTENCODING env
On Tue, 2013-08-27 at 17:36 +0300, Heikki Linnakangas wrote:
> Here is a set of three patches that I've been working on:
There is a compiler warning:
pg_backup_db.c:243:0: warning: "PARAMS_ARRAY_SIZE" redefined [enabled by
default]
pg_backup_db.c:139:0: note: this is the location of the previous
On 08/27/2013 11:14 AM, Heikki Linnakangas wrote:
On 27.08.2013 18:03, Andrew Dunstan wrote:
On 08/27/2013 10:36 AM, Heikki Linnakangas wrote:
0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch
Separates pg_dump -E from PGCLIENTENCODING.
Wouldn't it be better to do this another way?
On 27.08.2013 18:03, Andrew Dunstan wrote:
On 08/27/2013 10:36 AM, Heikki Linnakangas wrote:
0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch
Separates pg_dump -E from PGCLIENTENCODING.
Wouldn't it be better to do this another way? Separating these two will
be confusing, to say the
On 08/27/2013 10:36 AM, Heikki Linnakangas wrote:
0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch
Separates pg_dump -E from PGCLIENTENCODING.
Wouldn't it be better to do this another way? Separating these two will
be confusing, to say the least, as well as inconsistent with what
Heikki Linnakangas writes:
> When client encoding is not specified explicitly with the -E option, or
> PGCLIENTENCODING env variable, the dump is created in the server encoding.
Yeah, that's intentional as I recall.
> However, pg_dump is special, because client encoding affects not only
> the
pg_dump and pg_restore don't behave very nicely when the client and
server encodings don't match. Below are three issues that arise from
that. All the examples below use a console with a UTF-8 locale, and the
'latin1db' database uses ISO-8859-1 as the database encoding. In that
database, there