Horton

Thread

  1. NLS for extension

    Ed Behn <ed@behn.us> — 2024-03-21T11:48:57Z

    Good day-
    I'll start by admitting that I am a typical American who only speaks
one language.
    I maintain the PL./Haskell extension (
https://github.com/ed-o-saurus/PLHaskell). I recently received a bug report
from a user who is unable to load the extension when they have set lc_messages
to something other than 'C' or 'en_US.utf8' (
https://github.com/ed-o-saurus/PLHaskell/issues/9). I'm not sure how to
address this issue. I know it has something to do with NLS, but I'm
confused about what I need to do to get an extension to work. The
documentation in chapter 57 of the user's manual seems to address
stand-alone programs. At least that is my understanding.
    I am using my own makefile, not the one from pg_config.
    Any guidance would be appreciated.
                    -Ed

  2. Re: NLS for extension

    Robert Haas <robertmhaas@gmail.com> — 2024-03-21T12:49:09Z

    On Thu, Mar 21, 2024 at 7:49 AM Ed Behn <ed@behn.us> wrote:
>     I'll start by admitting that I am a typical American who only speaks one language.
>     I maintain the PL./Haskell extension (https://github.com/ed-o-saurus/PLHaskell). I recently received a bug report from a user who is unable to load the extension when they have set lc_messages to something other than 'C' or 'en_US.utf8' (https://github.com/ed-o-saurus/PLHaskell/issues/9). I'm not sure how to address this issue. I know it has something to do with NLS, but I'm confused about what I need to do to get an extension to work. The documentation in chapter 57 of the user's manual seems to address stand-alone programs. At least that is my understanding.
>     I am using my own makefile, not the one from pg_config.

That seems really weird. You wouldn't think that an NLS problem could
cause an invalid ELF header.

If I were trying to troubleshoot this, I'd set up the failing scenario
(i.e. lc_messages=pt_BR.utf8), set a breakpoint in the server on
errstart, and then perform the failing action. Then I'd use gdb to get
a backtrace from the point where the error was thrown, and hope that
the contents of that backtrace made it more clear what was actually
happening.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

  3. Re: NLS for extension

    Ed Behn <ed@behn.us> — 2024-03-22T13:26:41Z

    Robert-
    Thank you for your guidance. It turns out the call was coming from
inside the house. The error isn't caused by Postgres. It's the library that
I'm using that reported the error. My extension passes any errors it
generates as Postgres ERRORs.
          -Ed

On Thu, Mar 21, 2024 at 8:49 AM Robert Haas <robertmhaas@gmail.com> wrote:

> On Thu, Mar 21, 2024 at 7:49 AM Ed Behn <ed@behn.us> wrote:
> >     I'll start by admitting that I am a typical American who only speaks
> one language.
> >     I maintain the PL./Haskell extension (
> https://github.com/ed-o-saurus/PLHaskell). I recently received a bug
> report from a user who is unable to load the extension when they have set
> lc_messages to something other than 'C' or 'en_US.utf8' (
> https://github.com/ed-o-saurus/PLHaskell/issues/9). I'm not sure how to
> address this issue. I know it has something to do with NLS, but I'm
> confused about what I need to do to get an extension to work. The
> documentation in chapter 57 of the user's manual seems to address
> stand-alone programs. At least that is my understanding.
> >     I am using my own makefile, not the one from pg_config.
>
> That seems really weird. You wouldn't think that an NLS problem could
> cause an invalid ELF header.
>
> If I were trying to troubleshoot this, I'd set up the failing scenario
> (i.e. lc_messages=pt_BR.utf8), set a breakpoint in the server on
> errstart, and then perform the failing action. Then I'd use gdb to get
> a backtrace from the point where the error was thrown, and hope that
> the contents of that backtrace made it more clear what was actually
> happening.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>

  4. Re: NLS for extension

    Robert Haas <robertmhaas@gmail.com> — 2024-03-22T14:11:54Z

    On Fri, Mar 22, 2024 at 9:27 AM Ed Behn <ed@behn.us> wrote:
>     Thank you for your guidance. It turns out the call was coming from inside the house. The error isn't caused by Postgres. It's the library that I'm using that reported the error. My extension passes any errors it generates as Postgres ERRORs.

Yeah, I was kind of wondering if it was something like that. But I
figured it was a capital mistake to theorize in advance of the data.

Glad you figured it out.

-- 
Robert Haas
EDB: http://www.enterprisedb.com