FAQ

Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian:
Bruce Momjian wrote:
I have heavily modified your patch and have applied it. Instead of
using langinfo, I used a \pset variable numericsep.
Because I don't have langinfo on my system, so I can't test it, nor add
configure code for it. It also prevents us from using space as the
separator, which is the international standard.
OK, so let's discuss what we really want here.

The original submitter wanted locale-dependent output, which seems reasonable,
because that's what locale settings are intended for.

The current state allows users to manually set the format, or actually only
one aspect of the format? Where can you set the decimal separator and the
size of the grouping (3 digits or 4 digits)? Is this capability even useful
to get localized behavior?

My other concern is that if we allow manual specification of the output format
of some data type, then eventually someone will want to specify the format of
some other data type as well, such as the date/time types. We should think
about whether we want to be consistent here.

Search Discussions

  • Bruce Momjian at Jul 12, 2005 at 2:48 pm

    Peter Eisentraut wrote:
    Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian:
    Bruce Momjian wrote:
    I have heavily modified your patch and have applied it. Instead of
    using langinfo, I used a \pset variable numericsep.
    Because I don't have langinfo on my system, so I can't test it, nor add
    configure code for it. It also prevents us from using space as the
    separator, which is the international standard.
    OK, so let's discuss what we really want here.

    The original submitter wanted locale-dependent output, which seems reasonable,
    because that's what locale settings are intended for.
    True, but there were no locale configure tests, and I don't have
    langinfo, so I just made it a \pset 'string' variable. Also, when I
    learned that the international system uses a space to separate
    trigroups, a separate setting seemed best:

    http://en.wikipedia.org/wiki/Comma_%28punctuation%29#Numbers

    One thing we could do is to have a special value like 'locale' that uses
    langinfo, and all other values are taken literally.
    The current state allows users to manually set the format, or actually only
    one aspect of the format? Where can you set the decimal separator and the
    size of the grouping (3 digits or 4 digits)? Is this capability even useful
    to get localized behavior?
    You can't change the grouping from three, and the decimal is only be
    changed by setting the numeric separator to a period. We could add a
    new \pset for the decimal mark, but then do we auto-set it when the
    separator is a period?
    My other concern is that if we allow manual specification of the output format
    of some data type, then eventually someone will want to specify the format of
    some other data type as well, such as the date/time types. We should think
    about whether we want to be consistent here.
    We do allow MDY and DMY specification, but that controls both input and
    output in the server, while this just controls psql display. It is a
    good question how other settings should be handled, but I don't know the
    answers. Anyone?

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 359-1001
    + If your life is a hard drive, | 13 Roberts Road
    + Christ can be your backup. | Newtown Square, Pennsylvania 19073
  • Tom Lane at Jul 12, 2005 at 3:23 pm

    Bruce Momjian writes:
    We do allow MDY and DMY specification, but that controls both input and
    output in the server, while this just controls psql display. It is a
    good question how other settings should be handled, but I don't know the
    answers. Anyone?
    This patch sounds quite a lot different from what I thought we had
    agreed to, which was a way to specify that the client-side LC_NUMERIC
    locale settings should be used for formatting numbers. I think the only
    pset should be "locale on" or "locale not on". This business about
    space is a red herring: if you want that, create a locale spec that
    specifies it.

    regards, tom lane
  • Bruce Momjian at Jul 12, 2005 at 3:26 pm

    Tom Lane wrote:
    Bruce Momjian <pgman@candle.pha.pa.us> writes:
    We do allow MDY and DMY specification, but that controls both input and
    output in the server, while this just controls psql display. It is a
    good question how other settings should be handled, but I don't know the
    answers. Anyone?
    This patch sounds quite a lot different from what I thought we had
    agreed to, which was a way to specify that the client-side LC_NUMERIC
    locale settings should be used for formatting numbers. I think the only
    pset should be "locale on" or "locale not on". This business about
    space is a red herring: if you want that, create a locale spec that
    specifies it.
    Well, how many people have langinfo? I don't. If this is what the
    group wants, Someone with langinfo is going to have to code the
    configure tests and convert it to a binary setting, or remove the patch.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 359-1001
    + If your life is a hard drive, | 13 Roberts Road
    + Christ can be your backup. | Newtown Square, Pennsylvania 19073
  • Tom Lane at Jul 12, 2005 at 3:33 pm

    Bruce Momjian writes:
    Tom Lane wrote:
    This patch sounds quite a lot different from what I thought we had
    agreed to, which was a way to specify that the client-side LC_NUMERIC
    locale settings should be used for formatting numbers. I think the only
    pset should be "locale on" or "locale not on". This business about
    space is a red herring: if you want that, create a locale spec that
    specifies it.
    Well, how many people have langinfo? I don't.
    What's langinfo got to do with it? To minimize our portability
    exposure, the patch should use the same facilities that
    src/backend/utils/adt/pg_locale.c already depends on, namely
    setlocale() and localeconv().

    regards, tom lane
  • Bruce Momjian at Jul 12, 2005 at 3:50 pm

    Tom Lane wrote:
    Bruce Momjian <pgman@candle.pha.pa.us> writes:
    Tom Lane wrote:
    This patch sounds quite a lot different from what I thought we had
    agreed to, which was a way to specify that the client-side LC_NUMERIC
    locale settings should be used for formatting numbers. I think the only
    pset should be "locale on" or "locale not on". This business about
    space is a red herring: if you want that, create a locale spec that
    specifies it.
    Well, how many people have langinfo? I don't.
    What's langinfo got to do with it? To minimize our portability
    exposure, the patch should use the same facilities that
    src/backend/utils/adt/pg_locale.c already depends on, namely
    setlocale() and localeconv().
    The original patch included "langinfo.h" and used this call to set the
    default separator:

    char *dec_point = nl_langinfo(__DECIMAL_POINT);

    I don't see __DECIMAL_POINT defined anywhere on the FreeBSD 4.11 box we
    use for CVS.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 359-1001
    + If your life is a hard drive, | 13 Roberts Road
    + Christ can be your backup. | Newtown Square, Pennsylvania 19073
  • David Fetter at Jul 12, 2005 at 4:51 pm

    On Tue, Jul 12, 2005 at 10:48:40AM -0400, Bruce Momjian wrote:
    Peter Eisentraut wrote:
    Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian:
    Bruce Momjian wrote:
    The current state allows users to manually set the format, or
    actually only one aspect of the format? Where can you set the
    decimal separator and the size of the grouping (3 digits or 4
    digits)? Is this capability even useful to get localized
    behavior?
    You can't change the grouping from three,
    This makes it a non-starter, IMHO. One set of people who use 4 digits
    is this little ethnic group called the Chinese.
    My other concern is that if we allow manual specification of the
    output format of some data type, then eventually someone will want
    to specify the format of some other data type as well, such as the
    date/time types. We should think about whether we want to be
    consistent here.
    We do allow MDY and DMY specification, but that controls both input
    and output in the server, while this just controls psql display. It
    is a good question how other settings should be handled, but I don't
    know the answers. Anyone?
    Hrm. I think we can safely tackle input and output as separate
    features here. What do we do for to_char() with such separators?

    Cheers,
    D
    --
    David Fetter david@fetter.org http://fetter.org/
    phone: +1 510 893 6100 mobile: +1 415 235 3778

    Remember to vote!
  • Bruce Momjian at Jul 13, 2005 at 2:31 am

    David Fetter wrote:
    On Tue, Jul 12, 2005 at 10:48:40AM -0400, Bruce Momjian wrote:
    Peter Eisentraut wrote:
    Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian:
    Bruce Momjian wrote:
    The current state allows users to manually set the format, or
    actually only one aspect of the format? Where can you set the
    decimal separator and the size of the grouping (3 digits or 4
    digits)? Is this capability even useful to get localized
    behavior?
    You can't change the grouping from three,
    This makes it a non-starter, IMHO. One set of people who use 4 digits
    is this little ethnic group called the Chinese.
    I didn't know that.
    My other concern is that if we allow manual specification of the
    output format of some data type, then eventually someone will want
    to specify the format of some other data type as well, such as the
    date/time types. We should think about whether we want to be
    consistent here.
    We do allow MDY and DMY specification, but that controls both input
    and output in the server, while this just controls psql display. It
    is a good question how other settings should be handled, but I don't
    know the answers. Anyone?
    Hrm. I think we can safely tackle input and output as separate
    features here. What do we do for to_char() with such separators?
    Well, it isn't so much the input/output issue, but that the output
    control is only in psql. Is that OK? I don't image we could ever put
    input functionality in psql, only in the server.


    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 359-1001
    + If your life is a hard drive, | 13 Roberts Road
    + Christ can be your backup. | Newtown Square, Pennsylvania 19073
  • Tom Lane at Jul 12, 2005 at 4:33 pm

    Bruce Momjian writes:
    Ah, I see this now in our code:
    CurrentLocaleConv.decimal_point = strdup(extlconv->decimal_point);
    CurrentLocaleConv.grouping = strdup(extlconv->grouping);
    CurrentLocaleConv.thousands_sep = strdup(extlconv->thousands_sep);
    Is this what we should be using?
    That's what I'd think. We know that localeconv() is portable --- that
    code has been there for years.
    Does psql use any of this now (I think no).
    A quick grep shows this is the only call of localeconv() in our code.

    Note: it occurs to me that those strdup's could fail in low-memory
    conditions, and we're not checking. Probably the routine should
    be rewritten to palloc into TopMemoryContext. Will see about it.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 12, '05 at 12:57p
activeJul 13, '05 at 2:31a
posts9
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase