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 !

tupleDesc->attrs[i]->attlen in fastgetiattr.

Remove 'unused variable' from dt.c

Subject: [HACKERS] backend/utils/adt/timestamp.c

Back to this timezone stuff.  The struct tm has a field (tm_gmtoff) which
is the offset from UTC (GMT is archaic BTW) in seconds.  Is this the
value you are looking for when you use timezone?  Note that this applies
to NetBSD but it does not appear to be in either ANSI C or POSIX.  This
looks like one of those things that is just going to have to be hand
coded for each platform.

Why not just store the values in UTC and use localtime instead of
gmtime when retrieving the value?

Also, you assume the time is returned as a 4 byte integer.  In fact,
there is not even any requirement that time be an integral value.  You
should use time_t here.

The input function seems unduly restrictive.  Somewhere in the sources
there is an input function that allows words for months.  Can't we do
the same here?

There is a standard function, difftime, for subtracting two times.  It
deals with cases where time_t is not integral.  There is, however, a
small performance hit since it returns a double and I don't believe
there is any system currently which uses anything but an integral for
time_t.  Still, this is technically the correct and portable thing to do.

The returns from the various comparisons should probably be a bool.

Christoph Kaesling <ck@dog.pfalz.sub.de>

The first fixes a warning from gcc about the assignment within the condition.
The extra set of parens should not make a difference, but with -Werror, they
are necessary.

The second fixes an "ln -s" invocation that assumes the current directory is
implicitly the target if not specified.  Not true in all cases, and again, it
should not make a difference except to those implementation that it does.

From: "Michael P. Snyder" <msnyder@hawkeye.huntersmoon.com>

of endian.h.  I figure that if it exists it's pretty sure that it has
the byte order information and we may catch some other ports without
any further testing.

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

Pointed out indirectly by D'Arcy

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.