| Age | Commit message (Collapse) | Author |
|---|
|
|
|
but at least now it does what it's supposed to do ...
|
|
> > >
> > > This patch is in responce to the following TODO list item:
> > > * have psql \d on a view show the query
> > > -Ryan
|
|
an
embedded new-line character.
Billy G. Allie
|
|
results in a bogus datetime value under AlphaLinux. (Note that
the link to submit a port-specific bug on your website is broken)
-Test Case:
----------
testdb=> create table dttest (dt datetime);
testdb=> insert into dttest values ('now');
--------------------------------------------------------------------------
Solution:
---------
The basic problem is the typedefs of AbsoluteTime and RelativeTime,
which are both 'int32'. These types appear to be used synonymously
with the 'time_t' type, which on AlphaLinux is typedef'd as a 'long
int', which is 64-bits (not 32). The solution included here fixes
the datetime type (it now passes the regression test), but does not
pass the absolute and relative time regression tests. Presumably, a
more thorough investigation of how these types are used is warranted.
The included patch is from the v6.3.2 source, but can be applied to
the v6.4.2 source. Please note that there is also a RedHat-specific
patch distributed with the PostgreSQL source package from RedHat
that was applied first.
Rich Edwards
|
|
DwD
--
Daryl W. Dunbar
|
|
NetBSD/macppc
LinuxPPC
FreeBSD 2.2.6-RELEASE
All of them seem happy with the regression test. Note that, however,
compiling with optimization enabled on NetBSD/macppc causes an initdb
failure (other two platforms are ok). After checking the asm code, we
are suspecting that might be a compiler(egcs) bug.
Tatsuo Ishii
|
|
|
|
This change brings the default size of the main shmem block back under 1MB,
which is a fairly popular value for the kernel's SHMMAX parameter.
|
|
portability problem. Included patches should be applied to both
current and 6.4 tree. I have tested on LinuxPPC, FreeBSD and Solaris
2.6. Now the inet regression tests on these platforms are all happy.
---
Tatsuo Ishii
|
|
|
|
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
|
|
|
