Re: minor changes in psql's \encoding command

Weiping He <laser@zhengmai.com.cn> writes:
>   int
> ! PQclientEncoding(PGconn *conn)
>   {
> +     static char query[] = "show client_encoding";
> +     PGresult    *res;
> +     char    *encoding;
> +
>       if (!conn || conn->status != CONNECTION_OK)
>           return -1;
> +     res = PQexec(conn, query);
> +
> +     if(res == (PGresult *) NULL)
> +         return -1;
> +     if(res->resultStatus != PGRES_TUPLES_OK)
> +         return -1;
> +     else{
> +         encoding = PQgetvalue(res, 0, 0);
> +         conn->client_encoding = pg_char_to_encoding(encoding);
> +     }
> +     PQclear(res);
>       return conn->client_encoding;
>   }

I'm a bit dissatisfied with this, as (a) it fails utterly with pre-7.3
servers; (b) it fails if the server is in transaction-abort state;
(c) it fails if the client is in the middle of a query cycle already;
(d) it changes what had been an extremely cheap call into an extremely
expensive one.  (I shudder to think of the implications for an app that
calls it in an inner loop, as for example per-character during display
of results.)

This is quite a large change from the old behavior to support what seems
an unusual corner case.  How many clients have need to change encoding
on the fly?

I'd prefer to just document that PQclientEncoding is untrustworthy if
the client sets the encoding directly (rather than via PGCLIENTENCODING
or PQsetClientEncoding), and similarly that psql's \encoding is not
trustworthy if one goes behind its back.

            regards, tom lane