| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Fully update git head, and update back branches in ./COPYRIGHT and
legal.sgml files.
|
|
|
|
|
|
|
| |
the week via ISO or Gregorian designations. The fix is to store the
day-of-week consistently as 1-7, Sunday = 1.
Fixes bug reported by Marc Munro
|
| |
|
|
|
|
|
|
|
|
| |
century specifications just like positive/AD centuries. Previously the
behavior was either wrong or inconsistent with positive/AD handling.
Centuries without years now always assume the first year of the century,
which is now documented.
|
|
|
|
|
|
|
| |
The Solaris Studio compiler warns about these instances, unlike more
mainstream compilers such as gcc. But manual inspection showed that
the code is clearly not reachable, and we hope no worthy compiler will
complain about removing this code.
|
|
|
|
|
|
|
|
| |
A thinko in commit 029dfdf1157b6d837a7b7211cd35b00c6bcd767c caused the year
519 to be handled differently from either adjacent year, which was not the
intention AFAICS. Report and diagnosis by Marc Cousin.
In passing, remove redundant re-tests of year value.
|
|
|
|
| |
commit-fest.
|
|
|
|
| |
Josh Kupershmidt
|
|
|
|
|
| |
The tzn value might come from tm->tm_zone, which libc declares as
const, so it's prudent that the upper layers know about this as well.
|
|
|
|
| |
For clarity, following other sites, and to silence Coverity.
|
| |
|
|
|
|
|
| |
Always compare the return value to 0, don't use cute tricks like
if (!strcmp(...)).
|
|
|
|
|
| |
Remove some dead code, conditionally declare some items or call
some code, and fix one or two declarations.
|
|
|
|
|
|
|
|
| |
Trailing-zero stripping applied by the FM specifier could strip zeroes
to the left of the decimal point, for a format with no digit positions
after the decimal point (such as "FM999.").
Reported and diagnosed by Marti Raudsepp, though I didn't use his patch.
|
|
|
|
|
| |
they wrap toward year 2020, rather than the inconsistent behavior we had
before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions should take a pg_locale_t, not a collation OID, and should
call mbstowcs_l/wcstombs_l where available. Where those functions are not
available, temporarily select the correct locale with uselocale().
This change removes the bogus assumption that all locales selectable in
a given database have the same wide-character conversion method; in
particular, the collate.linux.utf8 regression test now passes with
LC_CTYPE=C, so long as the database encoding is UTF8.
I decided to move the char2wchar/wchar2char functions out of mbutils.c and
into pg_locale.c, because they work on wchar_t not pg_wchar_t and thus
don't really belong with the mbutils.c functions. Keeping them where they
were would have required importing pg_locale_t into pg_wchar.h somehow,
which did not seem like a good plan.
|
| |
|
|
|
|
|
|
|
|
| |
pg_newlocale_from_collation does not have enough context to give an error
message that's even a little bit useful, so move the responsibility for
complaining up to its callers. Also, reword ERRCODE_INDETERMINATE_COLLATION
error messages in a less jargony, more message-style-guide-compliant
fashion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Install just one instance of the "C" and "POSIX" collations into
pg_collation, rather than one per encoding. Make these instances exist
and do something useful even in machines without locale_t support: to wit,
it's now possible to force comparisons and case-folding functions to use C
locale in an otherwise non-C database, whether or not the platform has
support for using any additional collations.
Fix up severely broken upper/lower/initcap functions, too: the C/POSIX
fastpath now does what it is supposed to, and non-default collations are
handled correctly in single-byte database encodings.
Merge the two separate collation hashtables that were being maintained in
pg_locale.c, and be more wary of the possibility that we fail partway
through filling a cache entry.
|
| |
|
|
|
|
|
|
|
|
| |
This adds collation support for columns and domains, a COLLATE clause
to override it per expression, and B-tree index support.
Peter Eisentraut
reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
rather than only sort-of working as the previous attempt had left it.
Clean up some unnecessary differences between the way these were coded and
the way the YYYY case was coded. Update the regression test cases that
proved that it wasn't working.
|
|
|
|
|
|
|
| |
about the behavior.
Document that quotes in to_date, to_timestamp, to_number skip input
characters.
|
| |
|
| |
|
|
|
|
| |
improve documentation, and add C comment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to_char with HH, e.g.
to_char(interval '0d 0h 12m 44s', 'DD HH24 MI SS');
now returns:
00 00 12 44
not:
00 12 12 44
|
|
|
|
|
|
| |
honored by YYYY. Also document Oracle "toggle" FM behavior.
Per report from Guy Rouillier
|
| |
|
|
|
|
|
| |
The code in the new block was not reindented; it will be fixed by pgindent
eventually.
|
|
|
|
| |
Pavel Stehule, Brendan Jurd
|
|
|
|
|
| |
In what seems like an oversight, we used to treat 'TH' the same as lowercase
'th', but only with HH/HH12.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
even when not in FM mode. This improves compatibility with Oracle and with
our pre-8.4 behavior, as per bug #4862.
Brendan Jurd
Add a couple of regression test cases for this. In passing, get rid of the
labeling of the individual test cases; doesn't seem to be good for anything
except causing extra work when inserting a test...
Tom Lane
|
|
|
|
| |
provided by Andrew.
|
|
|
|
|
|
|
|
|
|
|
|
| |
to date, as per bug #4702 and subsequent discussion. In particular, make it
work for years specified using AD/BC or CC fields, and fix the test for "no
year specified" so that it doesn't trigger inappropriately for 1 BC (which it
was doing even in code paths that had nothing to do with to_timestamp). I
also did some minor code beautification in the non-ISO-day-number code path.
This area has been busted all along, but because the code has been rewritten
repeatedly, it would be considerable trouble to back-patch. It's such a
corner case that it doesn't seem worth the effort.
|
|
|
|
|
|
|
|
|
|
| |
format codes are misapplied to a numeric argument. (The code still produces
a pretty bogus error message in such cases, but I'll settle for stopping the
crash for now.) Per bug #4700 from Sergey Burladyan.
Problem exists in all supported branches, so patch all the way back.
In HEAD, also clean up some ugly coding in the nearby cache management
code.
|
|
|
|
|
|
|
|
|
| |
designations (AM/PM). Also separate out matching of a meridian with
periods (e.g. A.M.) and with those without.
Do the same for AD/BC.
Brendan Jurd
|
| |
|
|
|
|
|
|
|
|
|
|
| |
pg_database_encoding_max_length() predicts the maximum character length
returned by wchar2char(). Per Hiroshi Inoue, MB_CUR_MAX isn't usable on
Windows because we allow encoding = UTF8 when the locale says differently;
and getting rid of it seems a good idea on general principles because it
narrows our dependence on libc's locale API just a little bit more.
Also install a check for overflow of the buffer size computation.
|
|
|
|
|
|
|
|
|
|
|
| |
is treated like a non-digit separator. This fixes the inconsistency in
examples like:
to_timestamp('2008-01-2', 'YYYY-MM-DD') -- didn't work
and
to_timestamp('2008-1-02', 'YYYY-MM-DD') -- did work
|
| |
|
|
|
|
| |
maybe isalnum is returning a value with the low-order byte all zero?
|
|
|
|
| |
Alex Hunsaker
|
|
|
|
|
|
|
| |
erroneous input, rather than silently producing bizarre results as formerly
happened.
Brendan Jurd
|
|
|
|
|
|
|
|
|
|
| |
1. -i option should run vacuum analyze only on pgbench tables, not *all*
tables in database.
2. pre-run cleanup step was DELETE FROM HISTORY then VACUUM HISTORY.
This is just a slow version of TRUNCATE HISTORY.
Simon Riggs
|
|
|
|
|
|
|
|
| |
warnings. Clean up various unneeded cruft that was left behind after
creating those routines. Introduce some convenience functions str_tolower_z
etc to eliminate tedious and error-prone double arguments in formatting.c.
(Currently there seems no need to export the latter, but maybe reconsider
this later.)
|