int4 or int32

Peter Eisentraut <peter_e@gmx.net> writes:

Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
PG_GETARG_INT32 et al. Inconsistency everywhere.

The original convention was to use int4 etc at the SQL level, int32 etc
at the C level. However the typedefs int4 etc have to be visible in
the include/catalog/pg_*.h headers, and so there's been a certain amount
of leakage of those typedefs into the C sources.

I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you want to, I won't object.

I also have to plead guilty to having changed all the float-datatype
code to use float4 and float8 recently. This was mainly because the
existing typedefs for float32 and float64 had a built-in assumption
that these types would always be pass-by-reference, and I wanted to
abstract the code away from that assumption. We can't touch those
typedefs for a release or three (else we'll break existing user
functions written in C), so switching to the SQL-level names seemed
like the best bet. But it's not real consistent with the integer-type
naming conventions :-(

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
PG_GETARG_INT32 et al. Inconsistency everywhere.

The original convention was to use int4 etc at the SQL level, int32 etc
at the C level. However the typedefs int4 etc have to be visible in
the include/catalog/pg_*.h headers, and so there's been a certain amount
of leakage of those typedefs into the C sources.

I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you want to, I won't object.

I also have to plead guilty to having changed all the float-datatype
code to use float4 and float8 recently. This was mainly because the
existing typedefs for float32 and float64 had a built-in assumption
that these types would always be pass-by-reference, and I wanted to
abstract the code away from that assumption. We can't touch those
typedefs for a release or three (else we'll break existing user
functions written in C), so switching to the SQL-level names seemed
like the best bet. But it's not real consistent with the integer-type
naming conventions :-(

Tom, I am wondering. If we don't change to int4/int8 internally now,
will we ever do it? The function manager change seems like the only
good time to do it, if we ever will. Basically, I am asking if we
should drop backward C compatibility for 7.1 and bite the bullet on the
change?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you want to, I won't object.

Tom, I am wondering. If we don't change to int4/int8 internally now,
will we ever do it?

As I thought I'd just made clear, I'm against standardizing on int4/int8
at the C level. The average C programmer would think that "int8" is
a one-byte type, not an eight-byte type. There's way too much history
behind that for us to swim against the tide. Having different naming
conventions at the C and SQL levels seems a better approach, especially
since it will exist to some extent anyway (int != integer, for
instance).

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you want to, I won't object.

Tom, I am wondering. If we don't change to int4/int8 internally now,
will we ever do it?

As I thought I'd just made clear, I'm against standardizing on int4/int8
at the C level. The average C programmer would think that "int8" is
a one-byte type, not an eight-byte type. There's way too much history
behind that for us to swim against the tide. Having different naming
conventions at the C and SQL levels seems a better approach, especially
since it will exist to some extent anyway (int != integer, for
instance).

OK.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

There were only a few to fix, so I fixed them.

Peter Eisentraut <peter_e@gmx.net> writes:

Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
PG_GETARG_INT32 et al. Inconsistency everywhere.

The original convention was to use int4 etc at the SQL level, int32 etc
at the C level. However the typedefs int4 etc have to be visible in
the include/catalog/pg_*.h headers, and so there's been a certain amount
of leakage of those typedefs into the C sources.

I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you want to, I won't object.

I also have to plead guilty to having changed all the float-datatype
code to use float4 and float8 recently. This was mainly because the
existing typedefs for float32 and float64 had a built-in assumption
that these types would always be pass-by-reference, and I wanted to
abstract the code away from that assumption. We can't touch those
typedefs for a release or three (else we'll break existing user
functions written in C), so switching to the SQL-level names seemed
like the best bet. But it's not real consistent with the integer-type
naming conventions :-(

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

There were only a few to fix, so I fixed them.

I don't think it's a good idea to write unspecified-width "int" in
the struct decls for Interval and friends. If the compiler decides
someday that that's int8, things break because the physical size of
Interval etc. is hardwired over in pg_type.h. Use "int32", or
perhaps revert these to int4.

regards, tom lane

Done.

Bruce Momjian <pgman@candle.pha.pa.us> writes:

There were only a few to fix, so I fixed them.

I don't think it's a good idea to write unspecified-width "int" in
the struct decls for Interval and friends. If the compiler decides
someday that that's int8, things break because the physical size of
Interval etc. is hardwired over in pg_type.h. Use "int32", or
perhaps revert these to int4.

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

There were only a few to fix, so I fixed them.

Peter Eisentraut <peter_e@gmx.net> writes:

Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no

DatumGetInt4. fmgr has

Wait a sec !
The patch to timestamp.h and date.h replaces int4 with int instead of int32.
At least the timestamp.h struct is on disk stuff, thus the patch is not so good :-)

Andreas

[ Charset ISO-8859-1 unsupported, converting... ]

There were only a few to fix, so I fixed them.

Peter Eisentraut <peter_e@gmx.net> writes:

Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no

DatumGetInt4. fmgr has

Wait a sec !
The patch to timestamp.h and date.h replaces int4 with int instead of int32.
At least the timestamp.h struct is on disk stuff, thus the patch is not so good :-)

Fixed to int32 now.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026