
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


Thu, 10 Sep 1998 18:23:49 +0300
Daniel Kalchev <daniel@digsys.bg>
more on int8
> 
> 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)

Thu, 10 Sep 1998 12:14:28 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] more on int8
> 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

Thu, 10 Sep 1998 17:05:38 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] more on int8
> > 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)

Thu, 10 Sep 1998 13:57:13 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] more on int8
> > > 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

Fri, 11 Sep 1998 05:15:11 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] more on int8
> > > > 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)

Fri, 11 Sep 1998 02:14:28 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] more on int8
>>>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


Fri, 11 Sep 1998 10:09:03 +0300
Daniel Kalchev <daniel@digsys.bg>
Re: [HACKERS] more on int8 
> >>>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)

Fri, 11 Sep 1998 10:10:45 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] more on int8
   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

Fri, 11 Sep 1998 08:22:26 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] more on int8
> 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

Fri, 11 Sep 1998 15:53:13 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] more on int8
> > 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)

Fri, 11 Sep 1998 13:07:26 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] more on int8