| Age | Commit message (Collapse) | Author |
|---|
|
|
|
shared memory space allocation. It's a wonder we have not seen bug
reports traceable to this area ... it's quite clear that the routine
dir_realloc() has never worked correctly, for example.
|
|
Ok. I made patches replacing all of "#if FALSE" or "#if 0" to "#ifdef
NOT_USED" for current. I have tested these patches in that the
postgres binaries are identical.
|
|
(--with-maxbackends). Add a postmaster switch (-N backends) that allows
the limit to be reduced at postmaster start time. (You can't increase it,
sorry to say, because there are still some fixed-size arrays.)
Grab the number of semaphores indicated by min(MAXBACKENDS, -N) at
postmaster startup, so that this particular form of bogus configuration
is exposed immediately rather than under heavy load.
|
|
symmetry with regprocout.
|
|
|
|
decade, century, or millenium.
|
|
Fix problem with date_part() for timespan (had an offset of one)
when given decade, century, and millenium as arguments.
Reported by Ricardo J.C.Coelho.
|
|
Change #if FALSE to #if NOT_USED to avoid port problems.
Fix up pg_indent weirdness with function argument declarations.
|
|
|
|
test after new AllocSet code.
Activated optimal AllocSet blocksize and chunk limit.
Jan
|
|
Jan
|
|
|
|
|
|
for int8 support. configure now checks only snprintf() for int8 support,
not sprintf and sscanf as it used to. The reason for doing this is that
if we are supplying our own snprintf code (which does handle long long int),
we now only need working long long support in the compiler not in the
platform's C library. I have verified that int8 now passes regression test
on HPUX 9, and I think it should work on SunOS 4.1.* and other older
platforms if gcc is used.
|
|
o allow to use Big5 (a Chinese encoding used in Taiwan) as a client
encoding. In this case the server side encoding should be EUC_TW
o add EUC_TW and Big5 test cases to the regression and the mb test
(contributed by Jonah Kuo)
o fix mistake in include/mb/pg_wchar.h. An encoding id for EUC_TW was
not correct (was 3 and now is 4)
o update documents (doc/README.mb and README.mb.jp)
o update psql helpfile (bin/psql/psqlHelp.h)
--
Tatsuo Ishii
t-ishii@sra.co.jp
|
|
|
|
|
|
|
|
by about 10% which seems to be good for half a percent or so of a SELECT.
|
|
|
|
was causing it not to detect out-of-range float values, as evidenced by
failure of float8 regression test. I corrected that logic and also
modified expected float8 results to account for new error message
generated for out-of-range inputs.
|
|
buffering lost by not going through stdio anymore for client I/O.
|
|
|
|
|
|
|
|
They are not corrected now.
Allow the date type to accept BC dates.
Share more date/time validation declarations through dt.h.
|
|
|
|
|
|
|
|
|
|
to ensure that config.h is included as well.
|
|
Here is a first patch to cleanup the backend side of libpq.
This patch removes all external dependencies on the "Pfin" and "Pfout" that
are declared in pqcomm.h. These variables are also changed to "static" to
make sure.
Almost all the change is in the handler of the "copy" command - most other
areas of the backend already used the correct functions.
This change will make the way for cleanup of the internal stuff there - now
that all the functions accessing the file descriptors are confined to a
single directory.
|
|
when deciding whether a field is a year field. Assume *anything* longer
than 2 digits (if it isn't a special-case doy) is a valid year.
This should fix the "Y1K" and "Y10K" problems
pointed out by Massimo recently.
Check usage of BC to require a positive-valued year; before just used it
to flip the sign of the year without checking. This led to problems
near year zero.
Allow a 5 digit "concatenated date" of 2 digit year plus day of year.
Do 2->4 digit year correction for 6 and 5 digit "concatenated dates".
Somehow forgot this originally. Guess not many folks use it...
|
|
I think NAN is already guaranteed to be there from Jan's work on NUMERIC,
but perhaps HUGE_VAL needs some #ifndef's in the same place.
Should also include "-Infinity" as -HUGE_VAL sometime; not there yet.
|
|
overflow error on high precision calculations where temporary
huge precision is required.
Jan
|
|
taking a logarithm with a 400 digit precision worked with that bug
in place).
Jan
|
|
Jan
|
|
Jan
|
|
|
|
|
|
with some extra ugly sprintfs fixed. More work in this area is
needed still.
Göran Thyni
|
|
|
|
to give HAVE_TM_ZONE priority. This fixes glibc2 machines and any other
machine which passes both tests in configure.
Repair HAVE_TM_ZONE code which stuffs tm structure with date type values.
Same problems as were originally there before v6.1, but never noticed.
Thanks to Oleg for nagging :)
|
|
exponents.
Jan
|
|
and aggregates.
Jan
|
|
LOCK TABLE IN ... MODE
...implemented
|
|
|
|
|
|
|
