Re: [HACKERS] pg_stats queries versus per-database encodings

2009-01-21 Thread Bruce Momjian
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

Re: [HACKERS] pg_stats queries versus per-database encodings

2009-01-04 Thread Tom Lane
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

Re: [HACKERS] pg_stats queries versus per-database encodings

2009-01-04 Thread Heikki Linnakangas
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

[HACKERS] pg_stats queries versus per-database encodings

2009-01-03 Thread Tom Lane
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