Subject: Re: [PATCHES] SET DateStyle patches
On Tue, 22 Apr 1997, Thomas Lockhart wrote:
> Some more patches! These (try to) finish implementing SET variable TO value
> for "DateStyle" (changed the name from simply "date" to be more descriptive).
> This is based on code from Martin and Bruce (?), which was easy to modify.
> The syntax is
>
> SET DateStyle TO 'iso'
> SET DateStyle TO 'postgres'
> SET DateStyle TO 'sql'
> SET DateStyle TO 'european'
> SET DateStyle TO 'noneuropean'
> SET DateStyle TO 'us' (same as "noneuropean")
> SET DateStyle TO 'default' (current same as "postgres,us")
>
> ("european" is just compared for the first 4 characters, and "noneuropean"
> is compared for the first 7 to allow less typing).
>
> Multiple arguments are allowed, so SET datestyle TO 'sql,euro' is valid.
>
> My mods also try to implement "SHOW variable" and "RESET variable", but
> that part just core dumps at the moment. I would guess that my errors
> are obvious to someone who knows what they are doing with the parser stuff,
> so if someone (Bruce and/or Martin??) could have it do the right thing
> we will have a more complete set of what we need.
>
> Also, I would like to have a floating point precision global variable to
> implement "SET precision TO 10" and perhaps "SET precision TO 10,2" for
> float8 and float4, but I don't know how to do that for integer types rather
> than strings. If someone is fixing the SHOW and RESET code, perhaps they can
> add some hooks for me to do the floats while they are at it.
>
> I've left some remnants of variable structures in the source code which
> I did not use in the interests of getting something working for v6.1.
> We'll have time to clean things up for the next release...
Subject: [PORTS] Configure for DEC-Alpha
Configure script properly detects alpha-dec-osf4.0 machine, but
sets a default GENERIC template for it. I modified tempplate/.similar to
add alpha-dec-osf4.0=alpha. Then configure properly set the template to
alpha.
Subject: [PATCHES] Patch for configure.in to not ask for CASSERT
The following patch defaults to CASSERT, so it doesn't ask you. You can
still use --enable-cassert and --disable-cassert to do it explicitly.
Default: disabled
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
pg_proc.h still needs modifying, but this gets it in there so that we can
get around any compiler bugs. Will try and get the pg_proc.h entries done
up later tonight...
Subject: Re: [HACKERS] GEQO and views (rules)
Oke, this was caused by a classic bug :-/
I thougth, root->base_relation_list_ could be
represented as relid string 1-2-3-4- etc.
Instead, in case of views, the count of relids doesn't start with "1" but
maybe 4-5-6- etc . :-(
GEQO patch follows ... views are now all right.
2. PageWeights are variables now.
3. Fixed using ceil((double)selec*indextuples) as estimation
for expected heap pages: ceil((double)selec*relpages) now.
use sum(npages)/((nkeys == 1) ? 1 : nkeys + 1) as expected index page
estimation for multi-key quals - instead of sum(npages).
In old code npages for x > 10 and x < 20 is twice as for x > 10 - cool ?
'master' file
Commit mods to regress.sh so that split out tests are run...look forward
to finding out how to do a proper redirect to continue visual cleanup :)
Subject: [HACKERS] Fix for European dates
This apparently fixes the European date reading problem reported
by several (European) bleeding edge adopters. I tried a few test
cases and it doesn't break the non-EuroDate cases in my test suite.
FreeBSD
The Makefile(s) have all been cleaned up such that there is a single
LDFLAGS vs LD_ADD or LDADD or LDFLAGS or LDFLAGS_BE. The Makefile(s)
should be alot more straightforward then they were before...and
consistent
Further extended Makefile.global/build/configure so that we can
have a 'template' file for each OS (and each version of OS, as in BSDi)
which is used as much as possible to generate Makefile.global
Any future ports should look at using the template file as a basis,
before moving over to Makefile.global.
This will most probably break alot of the ports, atho I've tried to
be very neat about it...
Remove USE_LOCALE from Makefile.global.in
Add USE_LOCALE to build/configure/config.h
Add check for BUILDRUN in configure to make sure that build is run before
configure
Subject: [HACKERS] timestamp.c changes
I sent in changes previously and they were rejected because they didn't
follow ANSI spec. Here is the input part of the changes again. Even
though it allows more flexibility for inputting different formats, it
is also backwards compatible with the standard version. I have also
not changed the output format so it will still output the ANSI forms.
Is this acceptable to everyone?
Subject: [HACKERS] Aggregate function patches
Here are the aggregate function patches I originally sent in last December.
They fix sum() and avg() behavior for ints and floats when NULL values are
involved.
I was waiting to resubmit these until I had a chance to write a v6.0->v6.1
database upgrade script to ensure that existing v6.0 databases which have
not been reloaded for v6.1 do no break with the new aggregate behavior.
These scripts are included below. It's OK with me if someone wants to do
something different with the upgrade strategy, but something like this
was discussed a few weeks ago.
Also, there were a couple of small items which cropped up in doing a clean
install of 970403 (actually 970402 + 970403 changes since the full 970403
tar file appears to be damaged or at least suspect). They are the first
two patches below and can be omitted if desired (although I think they
aren't dangerous :).
Subject: [HACKERS] More date time functions
Here are some additional patches mostly related to the date and time
data types. It includes some type conversion routines to move between
the different date types and some other date manipulation routines such
as date_part(units,datetime).
I noticed Edmund Mergl et al's neat trick for getting function overloading
for builtin functions, so started to use that for the date and time stuff.
Later, if someone figures out how to get function overloading directly
for internal C code, then we can move to that technique.
These patches include documentation updates (don't faint!) for the built-in
man page. Doesn't yet include mention of timestamp, since I don't know
much about it and since it may change a bit to become a _real_ ANSI timestamp
which would include parser support for the declaration syntax (what do you
think, Dan?).
The patches were developed on the 970330 release, but have been rebuilt
off of the 970402 release. The first patch below is to get libpq to compile,
on my Linux box, but is not related to the rest of the patches and you can
choose not to apply that one at this time. Thanks in advance, scrappy!
Subject: [HACKERS] Patch: SET var TO 'val'
Here is a patch that adds a "SET variable TO 'somevalue'" capability
to the parser, and then calls the SetPGVariable() function (which does
just issue a elog(NOTICE) to see whether it works).
That's the framework for adding timezone/date format/language/...
stuff.
Subject: [HACKERS] Small patch to pgtclCmds.c
Hi I have made the following small change to the extensions I made to
pgtclCmds.c quite a while ago.
At the moment there is a -assignbyidx option to pg_result assigning the
returned tuples to an array by using the 1st field of the select statement
as the key to the array.
eg "select name,age from vitalstatistics" will result in an array with
myarray(peter) = 32
myarray(paul) = 45
Often I need to have a pseudo-multi dimentional
array eg. "select name,age from vitalstatistics where occupation='plummer'
I would like to be able to generate an array
newarray(peter,overpaid) = 32
So to add a arbitrary string to the key value I have extended
pg_result $res -assignbyidx $arrayname
to have an optional argument
pg_result $res -assignbyidx $arrayname $appendstr
So that that string is appended to the key value.
Subject: [HACKERS] locale patches !
Hi there,
here are little patches to get Postgres 6.1 works with locale stuff.
This is a patch against 970402.tar.gz, there are no problem to apply them
by hand to 6.0 release. Collate stuff tested about 1-2 months in real
working database but I'm sure there must be no problem. US hackers
could vote against locale implementation ( locale for sure will affect to
speed of postgres ), so I introduce variable USE_LOCALE which
controls locale stuff. Non-US users now could use ~* operator
for searching and <order by> for strings with nation alphabet.
Please, don't forget, as I did first time, to set environment variable
LC_CTYPE and LC_COLLATE because backend get locale information from them.
I start postmaster from a little script, assuming that shell is Bash shell
it looks like:
#!/bin/sh
export LC_CTYPE=koi8-r
export LC_COLLATE=koi8-r
postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'
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: Re: [HACKERS] abstime "now" broken
Yes, I broke 'now' :( with an attempt at a bug fix involving
servers running in the UTC/GMT timezone. These patches fix
the problem, and have been tested in GMT (+00 hours),
PST (-08), and NZT (+12) timezones which exercized the code for
various cases including across day boundaries. btw, this code
fixes the same type of problem for 'today', 'yesterday', 'tomorrow',
for DATETIME, ABSTIME, DATE and TIME types.
The bugfix itself is quite small, but I have accumulated other
changes in the datetime data type and include them here also.
One set of changes involves printing ISO-formatted dates and
is in response to the helpful information from Kurt Lidl regarding
ANSI SQL dates. I'll send another e-mail sometime soon discussing
more issues he has raised...
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
