Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> We could attack this by including source database's encoding in the
> >> shared-memory entries, and performing a conversion on the fly when
> >> reading out the data. However, what happens if the conversion fails?
>
> > The mo
Heikki Linnakangas writes:
> Tom Lane wrote:
>> We could attack this by including source database's encoding in the
>> shared-memory entries, and performing a conversion on the fly when
>> reading out the data. However, what happens if the conversion fails?
> The most useful behavior would be to
Tom Lane wrote:
I notice that the pg_stat_statements patch is applying pg_mbcliplen()
to query strings, in the fond illusion that it knows what encoding
they are in.
This brings up a bigger issue, namely that pg_stat_activity isn't
exactly encoding-proof either --- whatever encoding is in use in
I notice that the pg_stat_statements patch is applying pg_mbcliplen()
to query strings, in the fond illusion that it knows what encoding
they are in.
This brings up a bigger issue, namely that pg_stat_activity isn't
exactly encoding-proof either --- whatever encoding is in use in a
particular data