Makefile.global.
End result, if all goes well, should allow for much easier porting, since
there will no longer be a concept of a "port". Most, if not everything,
*should* be determined by configure, or by the compiler itself. Still
work to be done though :)
Subject: [HACKERS] Small date patches (resubmitted)
Here a some small patches for the date/time code. They set the default
output format for the datetime type to the traditional Postgres
style, and fix a date debugging declaration. I submitted these
a couple of days ago, but they might have gotten lost...
NOTE: the second patch to dt.c is what I believe D'Arcy submitted as well,
that I claimed was taken out...sorry D'Arcy, my fault :(
Subject: [HACKERS] More patches for date/time
I have accumulated several patches to add functionality to the datetime
and timespan data types as well as to fix reported porting bugs on non-BSD
machines. These patches are:
dt.c.patch - add datetime_part(), fix bugs
dt.h.patch - add quarter and timezone support, add prototypes
globals.c.patch - add time and timezone variables
miscadmin.h.patch - add time and timezone variables
nabstime.c.patch - add datetime conversion routine
nabstime.h.patch - add prototypes
pg_operator.h.patch - add datetime operators, clean up formatting
pg_proc.h.patch - add datetime functions, reassign conflicting date OIDs
pg_type.h.patch - add datetime and timespan data types
The dt.c and pg_proc.h patches are fairly large; the latter mostly because I tried
to get some columns for existing entries to line up.
of common routines in pqcomprim.c (pq communication primitives).
Not all adapted to it yet, but it's a start.
- Rewritten some of those routines, to write/read bigger chunks of
data, precomputing stuff in buffers instead of sending out byte
by byte.
- As a consequence, I need to know the endianness of the machine.
Currently I rely on getting it from machine/endian.h, but this
may not be available everywhere? (Who the hell thought it was
a good idea to pass integers to the backend the other way around
than the normal network byte order? *argl*)
- Libpq looks in the environment for magic variables, and upon
establishing a connection to the backend, sends it queries
of the form "SET var_name TO 'var_value'". This needs a change
in the backend parser (Mr. Parser, are you there? :)
- Currently it looks for two Env-Vars, namely PG_DATEFORMAT
and PG_FLOATFORMAT. What else makes sense? PG_TIMEFORMAT?
PG_TIMEZONE?
From: "Martin J. Laubach" <mjl@wwx.vip.at>
In particular, no more compiled-in default for PGDATA or LIBDIR. Commands
that need them need either invocation options or environment variables.
PGPORT default is hardcoded as 5432, but overrideable with options or
environment variables.
