| From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: handling unconvertible error messages |
| Date: | 2016-08-13 16:25:59 |
| Message-ID: | CAB=Je-GDgWXuoW5gOuZBg6pYg3wK4CP2Q_zHtZ=CzoodT2wuRQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom> while giving something at least passable in the cases
that are broken today.
Would you mind adding an explicit "encoding" field to the error message?
At least it would give clear explanation how to parse that message without
resorting to a guess dance.
The biggest problem is client has no idea how to parse backend error
messages. If implementing client_encoding properly is too hard at this
point in time, then I would rather have "encoding field" right in the
startup error message.
That "encoding" field would enable sending properly localized messages in
the future if "pre-connect client_encoding" would be implemented somehow.
Vladimir
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Victor Wagner | 2016-08-13 16:28:55 | Re: handling unconvertible error messages |
| Previous Message | Tom Lane | 2016-08-13 16:02:30 | Re: handling unconvertible error messages |