Subject: [PATCHES] date/time timezone patches (mail bounced?)
Here are some hacks to get timezone behavior for the various time
data types to be compatible with v6.0. Although we have some hooks
already installed to get timezone info from the client to the
server, it still isn't clear if that can correctly transfer enough
timezone info to make the behavior the same as if timezone info
were derived from the server as is now the case. We certainly
won't resolve it in a day, so I think we are stuck with server-only
timezones for v6.1.
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
Subject: [HACKERS] Another patch to configure.in
I heard very little in objections/approvals to defaulting some of the
parameters to configure. Enclosed is a patch to configure.in which
removes the questions for
PGPORT
USE_LOCALE
NOHBA
By default (i.e. assuming you don't put anything extra in the configure
command line), it assumes PGPORT=5432, USE_LOCAL=no and NOHBA=no (i.e.
HBA is turned on)
--with-pgport=PGPORT_NO Over-rides the PGPORT value
--enable-locale enables USE_LOCALE
--disable-hba disables HBA
Just for completeness:
--prefix=BASEDIR Defaults to /usr/local/pgsql
--with-template=TEMPLATE Defaults to asking you
Subject: [PATCHES] 970417: some large object patches
Two patches here, made against 970417. Both have to do with large
objects:
1. lobjfuncs was not initialized in PQconnectdb. This causes
failure later if large objects are used. (Someone already
caught this error in PQsetdb.)
2. Postgres functions lo_import and lo_export sometimes
produce garbage for the file names because the filename
strings aren't always terminated by \0. (VARDATA isn't
necessarily null terminated.)
Subject: [PATCHES] 970417: two more patches for large objects
Here are two more patches:
1. pg_getint doesn't properly set the status flag when
calling pqGetShort or pqGetLong. This is required when
accessing large objects via libpq. This, combined with
problem 1 above causes postgres to crash when postgres
tries to print out the message that the status was not
good.
2. ExceptionalCondition crashes when called with detail =
NULL. This patch prevents dereferencing the NULL.
Subject: [HACKERS] Patch: set date to euro/us postgres/iso/sql
Here a patch that implements a SET date for use by the datetime
stuff. The syntax is
SET date TO 'val[,val,...]'
where val is us (us dates), euro (european dates), postgres,
iso or sql.
Thomas is working on the integration in his datetime module.
I just needed to get the patch out before it went stale :)
table. The table name is de-allocated by the CommitTransactionCommand()
in vc_init() before it is copied in VacRel.data and sometimes this causes
a SIGSEGV. My patch simply moves the strcpy before vc_init.
Submitted by Massimo Dal Zotto <dz@cs.unitn.it>.
index tuple (logical position within A LEVEL). bti_oid & bti_dummy
taken off from BTItemData.
2. Fix for multi-column indices (nbtsearch.c):
_bt_binsrch() - for searches on internal pages having keysize <
number of attrs we point at the last item < the scankey, not at the
first item = the scankey;
_bt_moveright() - if keysize < number of attrs we compare scankey with
_last_ item on current page to decide should we move right or
not.
Subject: [HACKERS] Money integration patches
Here are patches to integrate the money data type. I have included
some math and aggregate functions and have made the locale support optional
by #ifdef USE_LOCALE bracketing of functions.
Modules affected are:
builtins.h.patch
cash.c.patch
cash.h.patch
main.c.patch
pg_aggregate.h.patch
pg_operator.h.patch
pg_proc.h.patch
pg_type.h.patch
I changed the data type to be pass-by-reference rather than by-value
to pave the way for a larger internal representation (64-bit ints?).
Also, I changed the tabbing of cash.c and cash.h to match most of
the other Postgres source code files (4 space indent, 8 spaces == 1 tab).
The locale stuff should be tested under another convention (Russian?)
but I don't know what the correct results should be so perhaps someone
else can give them a try. Will update docs and regression tests in
the next few days.
invalid macro definitions, the compiler complains about:
"pqcomprim.c", line 48.9: 1506-275 (S) Unexpected text ';' ignored.
"pqcomprim.c", line 61.9: 1506-275 (S) Unexpected text ';' ignored.
The ';' terminating the macro definition ntoh_s(n) on line 27 and
ntoh_l(n) on line 28 should be removed.
Pointed out by: Olaf Mittelstaedt <MSTAEDT@va-sigi.va.fh-ulm.de>
Makefile.global and move them to seperate 'include' makefiles
Over time, should become even more port specific:
ie. Makefile.BSD44_derived should be broken down into netbsd/freebsd
specific ports
Marc G. Fournier
Vadim B. Mikheev