Re: [HACKERS] what to do about unsupported encodings

2016-10-26 Thread Michael Paquier
On Thu, Oct 27, 2016 at 2:01 AM, Tom Lane  wrote:
> Slightly related: there are some callers such as PGLC_localeconv that
> aren't checking for a failure return.  Seems bad.

And also related to the patch trying to improve OOM handling in
pg_locale.c, the point being that elog() cannot be called as long as
the saved locales are not put back in place. The cleanest fix here
would be to use a goto to take the code past restoring the saved
locales, and then issue and ERROR. I think that it would be better to
hit those two stones at once on the other thread.

For the calls in fe-connect.c, why are the calls of
pg_get_encoding_from_locale() requesting to print a message on error?
Shouldn't the caller request to *not* print an error instead and then
store an error string in conn->errorMessage if the encoding is < 0? It
seems to me that at the end the right call is to just remove
write_message all together and let the caller decide the error message
it wants. For HEAD that would be a fine cleanup to do. A patch does
not look that complicated, I could get one out according to those
lines.

Thoughts?
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] what to do about unsupported encodings

2016-10-26 Thread Tom Lane
Peter Eisentraut  writes:
> pg_get_encoding_from_locale() in chklocale.c reports this when it finds
> a locale with an encoding it does not recognize:

> ereport(WARNING,
> (errmsg("could not determine encoding for locale \"%s\": codeset
> is \"%s\"",
> ctype, sys),
>errdetail("Please report this to .")));

> I guess we don't get many of these reports.  But when testing out all
> the locales that an OS provides, I can produce tons of warnings like
> this, mostly related to legacy encodings of various localities.

> Should we maintain a list to the effect of, these are encodings we have
> heard about but don't support?  Or should we just drop the "please
> report this" part?  I think the latter was added when we were still
> breaking in this code, but it seems to have held up well.

I agree we could do without that now.

Slightly related: there are some callers such as PGLC_localeconv that
aren't checking for a failure return.  Seems bad.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] what to do about unsupported encodings

2016-10-26 Thread Peter Eisentraut
pg_get_encoding_from_locale() in chklocale.c reports this when it finds
a locale with an encoding it does not recognize:

ereport(WARNING,
(errmsg("could not determine encoding for locale \"%s\": codeset
is \"%s\"",
ctype, sys),
   errdetail("Please report this to .")));

I guess we don't get many of these reports.  But when testing out all
the locales that an OS provides, I can produce tons of warnings like
this, mostly related to legacy encodings of various localities.

Should we maintain a list to the effect of, these are encodings we have
heard about but don't support?  Or should we just drop the "please
report this" part?  I think the latter was added when we were still
breaking in this code, but it seems to have held up well.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers