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] libpq variable set patch

  Just a small change, so the automatic variable setting on
connection startup actually works...

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'

Check nextval/currval permission in analyze.c.

Can't inherits from ...

sequences,...) and vc_delhilowstats(NULL->vrl_relid) ...

New funcs (nextval & currval) in pg_proc.h

Pointed out by: igor@cs.cs.miami.edu

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.

#ifdef is looking for the wrong value.

Some systems require limits.h to define DBL_MIN.

From: "D'Arcy J.M. Cain" <darcy@druid.net>

our READ lock on pg_index and let others to create indices too !