Thread: 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.
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
> > 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)
> 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
> > 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)
> > > 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
> > > > 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)
>>>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 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)
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
> 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
> > 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)