On 22 Aug 2003, Greg Stark wrote:
>
> So, I needed a way to sort using collation rules other than the one the
> database was built with. So I wrote up the following function exposing strxfrm
> with an extra parameter to specify the LC_COLLATE value to use.
>
> This is my first C function so I'm really unsure that I've done the right
> thing. For the most part I pattern-matched off the string_io code in the
> contrib directory.
>
> In particular I'm unsure about the code postgres-interfacing code in
> c_varcharxfrm which makes an extra copy of both parameters that are passed in
> and an extra copy of the result value. Are varchars guaranteed to be
> nul-terminated? If so I can dispose of two of the copies. And I can probably
> eliminate the copying of the result by alloting extra space when I allocate it
> initially.
>
> But more generally. Would it make more sense to use text or bytea or something
> else to store these opaque binary strings? At least with glibc they tend to be
> unreadable anyways.
>
> Other caveats: It's condemned to be permanently non-threadsafe because the
> whole locale system is a non thread-safe API. Also I fear some systems will
> leak memory like a sieve when you call setlocale a few thousand times instead
> of the 1 time at initialization that they foresaw. At least glibc doesn't seem
> to leak in my brief testing.
>
> If it's deemed a reasonable approach and nobody has any fatal flaws then I
> expect it would be useful to put in the contrib directory?
I'm not sure that ERROR if the locale cannot be put back is sufficient
(although that case should be rare or non-existant). Unless something else
in the system resets the locale, after your transaction rolls back, you're
in a dangerous state. I'd think FATAL would be better.