Thread: File not found error on creating collation
Hi, I don't find the following error message very helpful: =# create collation "sr_SP" (LOCALE ='sr_SB.utf8'); ERROR: could not create locale "sr_SB.utf8": No such file or directory It's correct in that it shouldn't be able to create the locale since it's not installed, but what file can't it find? What is the user supposed to do with this message? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Sep 20, 2011 at 03:24, Thom Brown <thom@linux.com> wrote: > ERROR: could not create locale "sr_SB.utf8": No such file or directory > > It's correct in that it shouldn't be able to create the locale since > it's not installed, but what file can't it find? What is the user > supposed to do with this message? Unfortunately locales are OS-specific so there's not much universal advice that Postgres could give. However, I guess it does make sense addressing this in documentation. On Linux you'd need to edit the /etc/locale.gen file and then run 'locale-gen' as root. Regards, Marti
Marti Raudsepp <marti@juffo.org> writes:
> On Tue, Sep 20, 2011 at 03:24, Thom Brown <thom@linux.com> wrote:
>> ERROR: could not create locale "sr_SB.utf8": No such file or directory
>> It's correct in that it shouldn't be able to create the locale since
>> it's not installed, but what file can't it find? What is the user
>> supposed to do with this message?
> Unfortunately locales are OS-specific so there's not much universal
> advice that Postgres could give.
The reason it's doing that is that newlocale() is returning ENOENT,
which is what it's supposed to do according to the standard:
ERRORS
The newlocale() function shall fail if:
[ENOMEM]There is not enough memory available to create the locale object or load the locale data.[EINVAL]The
category_maskcontains a bit that does not correspond to a valid category.[ENOENT]For any of the categories in
category_mask,the locale data is not available.
The generic meaning of ENOENT is "file not found", and at some level
this probably *is* a file-not-found situation, but Postgres has no way
to know which file is missing.
We could possibly add a HINT suggesting that the locale isn't installed,
but I don't see that we could offer any useful generic advice about how
to install it. I'm also worried about how to phrase the hint to cover
some other obvious possibilities, like "you fat-fingered the locale
name".
regards, tom lane
On Mon, Sep 19, 2011 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Marti Raudsepp <marti@juffo.org> writes: >> On Tue, Sep 20, 2011 at 03:24, Thom Brown <thom@linux.com> wrote: >>> ERROR: could not create locale "sr_SB.utf8": No such file or directory >>> It's correct in that it shouldn't be able to create the locale since >>> it's not installed, but what file can't it find? What is the user >>> supposed to do with this message? > >> Unfortunately locales are OS-specific so there's not much universal >> advice that Postgres could give. > > The reason it's doing that is that newlocale() is returning ENOENT, > which is what it's supposed to do according to the standard: > > ERRORS > > The newlocale() function shall fail if: > > [ENOMEM] > There is not enough memory available to create the locale object or load the locale data. > [EINVAL] > The category_mask contains a bit that does not correspond to a valid category. > [ENOENT] > For any of the categories in category_mask, the locale data is not available. > > The generic meaning of ENOENT is "file not found", and at some level > this probably *is* a file-not-found situation, but Postgres has no way > to know which file is missing. > > We could possibly add a HINT suggesting that the locale isn't installed, > but I don't see that we could offer any useful generic advice about how > to install it. I'm also worried about how to phrase the hint to cover > some other obvious possibilities, like "you fat-fingered the locale > name". Maybe something like this? HINT: The operating system was unable to find any locale data for the locale name you specified. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Sep 19, 2011 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We could possibly add a HINT suggesting that the locale isn't installed,
>> but I don't see that we could offer any useful generic advice about how
>> to install it. I'm also worried about how to phrase the hint to cover
>> some other obvious possibilities, like "you fat-fingered the locale
>> name".
> Maybe something like this?
> HINT: The operating system was unable to find any locale data for the
> locale name you specified.
Hmm, that's not bad. We could probably even call it errdetail, since
it's not so much a hint as explaining what the SUS spec states that the
ENOENT error code means here.
In the nitpick department, s/was unable to/could not/ per our usual
message style guidelines. Otherwise seems good.
regards, tom lane
On 20 September 2011 05:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Sep 19, 2011 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> We could possibly add a HINT suggesting that the locale isn't installed, >>> but I don't see that we could offer any useful generic advice about how >>> to install it. I'm also worried about how to phrase the hint to cover >>> some other obvious possibilities, like "you fat-fingered the locale >>> name". > >> Maybe something like this? > >> HINT: The operating system was unable to find any locale data for the >> locale name you specified. > > Hmm, that's not bad. We could probably even call it errdetail, since > it's not so much a hint as explaining what the SUS spec states that the > ENOENT error code means here. > > In the nitpick department, s/was unable to/could not/ per our usual > message style guidelines. Otherwise seems good. Sounds good to me. If this is to be the errdetail, does that mean you'd be keeping the original message in tact? The problem with the actual error message is that it might cause the user to think along the lines of "Am I supposed to put a fully qualified path in this parameter?". -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Thom Brown <thom@linux.com> writes:
> On 20 September 2011 05:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Maybe something like this?
>>> HINT: The operating system was unable to find any locale data for the
>>> locale name you specified.
>> Hmm, that's not bad. We could probably even call it errdetail, since
>> it's not so much a hint as explaining what the SUS spec states that the
>> ENOENT error code means here.
> Sounds good to me. If this is to be the errdetail, does that mean
> you'd be keeping the original message in tact? The problem with the
> actual error message is that it might cause the user to think along
> the lines of "Am I supposed to put a fully qualified path in this
> parameter?".
[ shrug... ] And who's to say that that's wrong? We have no knowledge
of the OS's conventions for naming locales. There's a limit to how
friendly we can make this message without turning it into something
that's actively misleading for platforms we failed to consider.
regards, tom lane
Thom Brown <thom@linux.com> writes:
> [ unhelpful reporting of ENOENT from newlocale() ]
BTW, on examining the code I note that we're doing something else that
promotes the confusion of "bad locale name" with "bad file name": we're
using errcode_for_file_access() to select the SQLSTATE. If we don't
believe that ENOENT should be taken at face value then this is pointless
(none of the other spec-defined error codes for newlocale() are
particularly sensible as file access errors). I propose just reporting
ERRCODE_INVALID_PARAMETER_VALUE instead.
regards, tom lane
On 20 September 2011 17:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> [ unhelpful reporting of ENOENT from newlocale() ] > > BTW, on examining the code I note that we're doing something else that > promotes the confusion of "bad locale name" with "bad file name": we're > using errcode_for_file_access() to select the SQLSTATE. If we don't > believe that ENOENT should be taken at face value then this is pointless > (none of the other spec-defined error codes for newlocale() are > particularly sensible as file access errors). I propose just reporting > ERRCODE_INVALID_PARAMETER_VALUE instead. *nods* -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Thom Brown <thom@linux.com> writes:
> On 20 September 2011 17:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, on examining the code I note that we're doing something else that
>> promotes the confusion of "bad locale name" with "bad file name": we're
>> using errcode_for_file_access() to select the SQLSTATE. �If we don't
>> believe that ENOENT should be taken at face value then this is pointless
>> (none of the other spec-defined error codes for newlocale() are
>> particularly sensible as file access errors). �I propose just reporting
>> ERRCODE_INVALID_PARAMETER_VALUE instead.
> *nods*
OK, done.
regards, tom lane
On 20 September 2011 18:25, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> On 20 September 2011 17:45, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> BTW, on examining the code I note that we're doing something else that >>> promotes the confusion of "bad locale name" with "bad file name": we're >>> using errcode_for_file_access() to select the SQLSTATE. If we don't >>> believe that ENOENT should be taken at face value then this is pointless >>> (none of the other spec-defined error codes for newlocale() are >>> particularly sensible as file access errors). I propose just reporting >>> ERRCODE_INVALID_PARAMETER_VALUE instead. > >> *nods* > > OK, done. Thanks. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company