French uses "" for "don't want".  Seems we have to keep the existing
behavior.

report from French Debian user.  psql already handles "" fine.

Euler Taveira de Oliveira

Map them to a single day, so '30 hours' is 'AM'.

Have to_char(interval) and to_char(time) use "HH", "HH12" as 12-hour
intervals, rather than bypass and print the full interval hours.  This
is neeeded because to_char(time) is mapped to interval in this function.
Intervals should use "HH24", and document suggestion.

Allow "D" format specifiers for interval/time.

comment line where output as too long, and update typedefs for /lib
directory.  Also fix case where identifiers were used as variable names
in the backend, but as typedefs in ecpg (favor the backend for
indenting).

Backpatch to 8.1.X.

Per gripe from Chris Matheson.

Fix to_char(interval) to return large year/month/day/hour values that
are larger than possible timestamp values.
Prevent to_char(interval) format specifications that make no sense, like
Month.
Clean up formatting.c code to more logically handle return lengths.

integer with flags.

parentheses. This avoids possible operator precedence problems, and
is consistent with most of the macro definitions in the tree.

near daylight savings time boudaries.  This handles it properly, e.g.

        test=> select '2005-04-03 04:00:00'::timestamp at time zone
        'America/Los_Angeles';
                timezone
        ------------------------
         2005-04-03 07:00:00-04
        (1 row)

	#define DAYS_PER_YEAR   365.25
	#define MONTHS_PER_YEAR 12
	#define DAYS_PER_MONTH  30
	#define HOURS_PER_DAY   24

24 hours. This is very helpful for daylight savings time:

	select '2005-05-03 00:00:00 EST'::timestamp with time zone + '24 hours';
	      ?column?
	----------------------
	2005-05-04 01:00:00-04

	select '2005-05-03 00:00:00 EST'::timestamp with time zone + '1 day';
	      ?column?
	----------------------
	2005-05-04 01:00:00-04

Michael Glaesemann

is redundant after a check has already been made for "num < 0". The "set"
variable can also be removed, as it is now no longer used. Per checking
with Karel, this is the right fix.

Per Coverity static analysis performed by EnterpriseDB.

"AT TIME ZONE", and not just the shorlist previously available. For
example:

SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London';

works fine now. It will also obey whatever DST rules were in effect at
just that date, which the previous implementation did not.

It also supports the AT TIME ZONE on the timetz datatype. The whole
handling of DST is a bit bogus there, so I chose to make it use whatever
DST rules are in effect at the time of executig the query. not sure if
anybody is actuallyi *using* timetz though, it seems pretty
unpredictable just because of this...

Magnus Hagander

them, the executation behavior could be unexpected.

when a zero-month interval is given.  Per discussion with Karel.
Also, some desultory const-labeling of constant tables.  More could be
done along that line.

Karel Zak

of an sprintf() as a source string.  Demonstrably does not work with
recent gcc and/or glibc on some platforms.

Karel Zak

- remove another senseless "extern" keyword that was applied to a
function definition
- change a foo more function signatures from "some_type foo()" to
"some_type foo(void)"
- rewrite another K&R style function definition
- make the type of the "action" function pointer in the KeyWord struct
in src/backend/utils/adt/formatting.c more precise

and should do now that we control our own destiny for timezone handling,
but this commit gets the bulk of the picayune diffs in place.
Magnus Hagander and Tom Lane.

conversion of basic ASCII letters.  Remove all uses of strcasecmp and
strncasecmp in favor of new functions pg_strcasecmp and pg_strncasecmp;
remove most but not all direct uses of toupper and tolower in favor of
pg_toupper and pg_tolower.  These functions use the same notions of
case folding already developed for identifier case conversion.  I left
the straight locale-based folding in place for situations where we are
just manipulating user data and not trying to match it to built-in
strings --- for example, the SQL upper() function is still locale
dependent.  Perhaps this will prove not to be what's wanted, but at
the moment we can initdb and pass regression tests in Turkish locale.

Fix to_char(year) for BC dates.  Previously it returned one less than
the current year.

Add documentation mentioning that there is no 0 AD.

pointer type when it is not necessary to do so.

For future reference, casting NULL to a pointer type is only necessary
when (a) invoking a function AND either (b) the function has no prototype
OR (c) the function is a varargs function.

> > needed, and other people in the past asked about it too.
>
> It is in Oracle, but you aren't exactly on the spot.  It should be
>
> IYYY - 4 digits  ('2003')
> IYY  - 3 digits  ('003')
> IY   - 2 digits  ('03')
> I    - 1 digit   ('3')

Here is an updated patch that does that.

Kurt Roeckx

$Header: -> $PostgreSQL Changes ...

From Karel Zak.

perform a timestamp-to-date coercion.  Instead both routines share a
subroutine that delivers the parsing result as a struct tm.  This avoids
problems with timezone dependency of to_date's result, and should be
at least marginally faster too.