owner-pgsql-hackers-digest@hub.org said:
the long long int printf format in int8.h is %lld on AIX
This is on my list. %lld will work with gcc also, so since we don't
have very many reported successful ports for int8, we should just
change it for now.
Tom,

I tried the int8 type onder BSD/OS, running 6.3.2 (contrib/int8). There the
%Ld type is unimplemented and %lld or %qd both work.

For BSD/OS 3.1, since DLSUFFIX is .o (static shared libraries), there is a
circular dependence in the Makefile. This is resolved by commenting out (or
ifdefing) the following segment:

int8$(DLSUFFIX): int8.o
$(CC) -shared -o int8$(DLSUFFIX) int8.o $(CLIBS)

Under BSD/OS 4.0 this should not be neccesary, as it supports Linux style
shared libraries.

I am missing the aggregate functions, such as sum() to deal with int8. Perhaps
these could be easily added? Is there problem to add all functionality that
exists for int4 to the int8 type?

Daniel

Search Discussions

  • Bruce Momjian at Sep 10, 1998 at 4:28 pm

    owner-pgsql-hackers-digest@hub.org said:
    the long long int printf format in int8.h is %lld on AIX
    This is on my list. %lld will work with gcc also, so since we don't
    have very many reported successful ports for int8, we should just
    change it for now.
    Tom,

    I tried the int8 type onder BSD/OS, running 6.3.2 (contrib/int8). There the
    %Ld type is unimplemented and %lld or %qd both work.
    I have added %qd support for the 6.4 beta release last night.
    For BSD/OS 3.1, since DLSUFFIX is .o (static shared libraries), there is a
    circular dependence in the Makefile. This is resolved by commenting out (or
    ifdefing) the following segment:

    int8$(DLSUFFIX): int8.o
    $(CC) -shared -o int8$(DLSUFFIX) int8.o $(CLIBS)

    Under BSD/OS 4.0 this should not be neccesary, as it supports Linux style
    shared libraries.
    I never saw this on BSDI 3.1. Oh, this must be in the /contrib
    directory. That contrib is gone in 6.4, and merged into the main
    backend. I have added BSDI 4.0 support for the upcoming 6.4 release
    next month.
    I am missing the aggregate functions, such as sum() to deal with int8. Perhaps
    these could be easily added? Is there problem to add all functionality that
    exists for int4 to the int8 type?

    --
    Bruce Momjian | 830 Blythe Avenue
    maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
    + If your life is a hard drive, | (610) 353-9879(w)
    + Christ can be your backup. | (610) 853-3000(h)
  • Thomas G. Lockhart at Sep 10, 1998 at 5:05 pm

    I tried the int8 type under BSD/OS, running 6.3.2 (contrib/int8).
    There the %Ld type is unimplemented and %lld or %qd both work.
    For BSD/OS 3.1, since DLSUFFIX is .o (static shared libraries), there
    is a circular dependence in the Makefile. This is resolved by
    commenting out (or ifdefing) the following segment:
    int8$(DLSUFFIX): int8.o
    $(CC) -shared -o int8$(DLSUFFIX) int8.o $(CLIBS)
    Under BSD/OS 4.0 this should not be neccesary, as it supports Linux
    style shared libraries.
    I am missing the aggregate functions, such as sum() to deal with int8.
    Is there problem to add all functionality that
    exists for int4 to the int8 type?
    int8 is a native built-in type for the next release of Postgres. Would
    you be willing to try beta testing the package and we can work out how
    to support BSD/OS?

    It may be that no changes would be necessary for you, since we are now
    using "%lld" for the default printf/scanf formatting string. But you
    would have to try an installation and see if "configure" catches the
    right characteristics of your system. The shared library won't be an
    issue since everything is now built in.

    Regards.

    - Tom
  • Bruce Momjian at Sep 10, 1998 at 5:58 pm

    I tried the int8 type under BSD/OS, running 6.3.2 (contrib/int8).
    There the %Ld type is unimplemented and %lld or %qd both work.
    For BSD/OS 3.1, since DLSUFFIX is .o (static shared libraries), there
    is a circular dependence in the Makefile. This is resolved by
    commenting out (or ifdefing) the following segment:
    int8$(DLSUFFIX): int8.o
    $(CC) -shared -o int8$(DLSUFFIX) int8.o $(CLIBS)
    Under BSD/OS 4.0 this should not be neccesary, as it supports Linux
    style shared libraries.
    I am missing the aggregate functions, such as sum() to deal with int8.
    Is there problem to add all functionality that
    exists for int4 to the int8 type?
    int8 is a native built-in type for the next release of Postgres. Would
    you be willing to try beta testing the package and we can work out how
    to support BSD/OS?

    It may be that no changes would be necessary for you, since we are now
    using "%lld" for the default printf/scanf formatting string. But you
    would have to try an installation and see if "configure" catches the
    right characteristics of your system. The shared library won't be an
    issue since everything is now built in.
    I am running BSD/OS here, and configure recoginizes it with %qd.

    --
    Bruce Momjian | 830 Blythe Avenue
    maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
    + If your life is a hard drive, | (610) 353-9879(w)
    + Christ can be your backup. | (610) 853-3000(h)
  • Thomas G. Lockhart at Sep 11, 1998 at 5:16 am

    I tried the int8 type under BSD/OS, running 6.3.2 (contrib/int8).
    There the %Ld type is unimplemented and %lld or %qd both work.
    I am running BSD/OS here, and configure recoginizes it with %qd.
    Just out of curiosity, does Bruce's BSDI system recognize %lld as did
    Daniel's? If so, we could dispense with the %qd option for the final
    release...

    - Tom
  • Bruce Momjian at Sep 11, 1998 at 6:15 am

    I tried the int8 type under BSD/OS, running 6.3.2 (contrib/int8).
    There the %Ld type is unimplemented and %lld or %qd both work.
    I am running BSD/OS here, and configure recoginizes it with %qd.
    Just out of curiosity, does Bruce's BSDI system recognize %lld as did
    Daniel's? If so, we could dispense with the %qd option for the final
    release...
    Yes, BSDI understands %lld, but not %Ld, though it is not documented in
    the printf manual page.

    We could probably do without %qd, but I assume their are some platforms
    that support %qd and not %lld. We can ask people as they run configure
    if they ever see %lld failing but %qd passing.

    --
    Bruce Momjian | 830 Blythe Avenue
    maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
    + If your life is a hard drive, | (610) 353-9879(w)
    + Christ can be your backup. | (610) 853-3000(h)
  • Daniel Kalchev at Sep 11, 1998 at 7:10 am

    Bruce Momjian said:
    Just out of curiosity, does Bruce's BSDI system recognize %lld as did
    Daniel's? If so, we could dispense with the %qd option for the final
    release...
    >
    Yes, BSDI understands %lld, but not %Ld, though it is not documented in
    the printf manual page.
    It is documented in the scanf manual page, where it says:

    l Indicates either that the conversion will be one of dioux or n
    and the next pointer is a pointer to a long int (rather than
    int), or that the conversion will be one of efg and the next
    pointer is a pointer to double (rather than float). If the con-
    version is dioux or n and two l flags are given, then the next
    pointer will be a pointer to a double precision integer of quad_t
    or u_quad_t (unsigned) type; these types are defined in
    <sys/types.h>.

    L Indicates that the conversion will be efg and the next pointer is
    a pointer to long double. (This type is not implemented; the L
    flag is currently ignored.)

    q Indicates a double precision integer conversion; identical to us-
    ing ll.

    Note the reference to u_quad_t - there is also quad_t in BSD/OS 3.1 which is
    singned. There are also (identical) types

    typedef u_int64_t u_quad_t; /* quads */
    typedef int64_t quad_t;

    The same is valid for BSD/OS 4.0.
    We could probably do without %qd, but I assume their are some platforms
    that support %qd and not %lld. We can ask people as they run configure
    if they ever see %lld failing but %qd passing.
    Perhaps %lld is GNUism? So it should work on most GNU based compilers. I agree
    your approach is good - to just sample the different platforms on which
    PostgreSQL is compiled.

    Daniel
  • Bruce Momjian at Sep 11, 1998 at 2:13 pm

    Bruce Momjian said:
    Just out of curiosity, does Bruce's BSDI system recognize %lld as did
    Daniel's? If so, we could dispense with the %qd option for the final
    release...
    Yes, BSDI understands %lld, but not %Ld, though it is not documented in
    the printf manual page.
    It is documented in the scanf manual page, where it says:

    l Indicates either that the conversion will be one of dioux or n
    and the next pointer is a pointer to a long int (rather than
    int), or that the conversion will be one of efg and the next
    pointer is a pointer to double (rather than float). If the con-
    version is dioux or n and two l flags are given, then the next
    pointer will be a pointer to a double precision integer of quad_t
    or u_quad_t (unsigned) type; these types are defined in
    <sys/types.h>.
    Yes, I see it now in the printf manual page:

    u_quad_t types are defined in <sys/types.h>. Two l conversion option
    characters are equivalent to a single q.
    L Indicates that the conversion will be efg and the next pointer is
    a pointer to long double. (This type is not implemented; the L
    flag is currently ignored.)

    q Indicates a double precision integer conversion; identical to us-
    ing ll.

    Note the reference to u_quad_t - there is also quad_t in BSD/OS 3.1 which is
    singned. There are also (identical) types

    typedef u_int64_t u_quad_t; /* quads */
    typedef int64_t quad_t;

    The same is valid for BSD/OS 4.0.
    We could probably do without %qd, but I assume their are some platforms
    that support %qd and not %lld. We can ask people as they run configure
    if they ever see %lld failing but %qd passing.
    Perhaps %lld is GNUism? So it should work on most GNU based compilers. I agree
    your approach is good - to just sample the different platforms on which
    PostgreSQL is compiled.
    Not sure if we should remove %qd, or keep it an wait. May just wait to
    see how many people support just %qd.

    Looks like I messed up the config.h.in define for lld again, so I am
    fixing it now.

    --
    Bruce Momjian | 830 Blythe Avenue
    maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
    + If your life is a hard drive, | (610) 353-9879(w)
    + Christ can be your backup. | (610) 853-3000(h)
  • Brook Milligan at Sep 11, 1998 at 2:22 pm
    We could probably do without %qd, but I assume their are some platforms
    that support %qd and not %lld. We can ask people as they run configure
    if they ever see %lld failing but %qd passing.

    One data point: netbsd v1.3.2/i386 (native compiler is gcc) likes both.

    Cheers,
    Brook
  • Thomas G. Lockhart at Sep 11, 1998 at 3:57 pm

    We could probably do without %qd, but I assume their are some
    platforms that support %qd and not %lld. We can ask people as they
    run configure if they ever see %lld failing but %qd passing.
    Could we please leave all of the hooks for %qd in the code, but disable
    the automatic check for it in configure.in and configure? If we run into
    a case which requires it, then it will be trivial to re-enable it (or if
    you like allow a manual override --enable-int8-qd). If we do not run
    into such a case then we can remove the code later, simplifying things a
    bit.

    If we don't disable it for now, then we will never be able to discover
    whether it is a required feature or not. Now is the time to do this
    since int8 is a new feature. It won't work very well to try the same
    tactic 6 months from now :)

    Thanks.

    - Tom
  • Bruce Momjian at Sep 11, 1998 at 5:08 pm

    We could probably do without %qd, but I assume their are some
    platforms that support %qd and not %lld. We can ask people as they
    run configure if they ever see %lld failing but %qd passing.
    Could we please leave all of the hooks for %qd in the code, but disable
    the automatic check for it in configure.in and configure? If we run into
    a case which requires it, then it will be trivial to re-enable it (or if
    you like allow a manual override --enable-int8-qd). If we do not run
    into such a case then we can remove the code later, simplifying things a
    bit.

    If we don't disable it for now, then we will never be able to discover
    whether it is a required feature or not. Now is the time to do this
    since int8 is a new feature. It won't work very well to try the same
    tactic 6 months from now :)
    OK, %qd removed.

    --
    Bruce Momjian | 830 Blythe Avenue
    maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
    + If your life is a hard drive, | (610) 353-9879(w)
    + Christ can be your backup. | (610) 853-3000(h)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 10, '98 at 3:24p
activeSep 11, '98 at 5:08p
posts11
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase