From: | Weiping He <laser(at)zhengmai(dot)com(dot)cn> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: minor changes in psql's \encoding command |
Date: | 2003-01-05 05:13:38 |
Message-ID: | 3E17BF02.2040102@zhengmai.com.cn |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
>
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
emm, understood your concern. documentation it seems better.
let me see if there better way to solve our problem.
regards laser
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-05 05:17:04 | Re: minor changes in psql's \encoding command |
Previous Message | Tom Lane | 2003-01-05 03:33:39 | Re: minor changes in psql's \encoding command |