Tom Lane [Sun, 9 Jan 2000 06:30:55 +0000 (06:30 +0000)]
Remove obsolete platform-specific regress test comparison files.
Note: don't put any of these back till you've grokked the new code for
platform-specific comparisons that I'm about to commit...
Tom Lane [Sun, 9 Jan 2000 04:01:49 +0000 (04:01 +0000)]
Remove CVS $Header lines from a couple of regress test files that had
them --- it is just *way* too painful to keep expected results in sync
when these are present.
Tom Lane [Sun, 9 Jan 2000 03:48:39 +0000 (03:48 +0000)]
Update remaining tests for new psql, with the exception of 'arrays',
which is broken in some weird way that I don't understand. I think it
may be exposing a bug in the new psql --- for one thing, I get different
results when I run psql by hand than the regress script gets. What
the heck???
Tom Lane [Sun, 9 Jan 2000 00:26:47 +0000 (00:26 +0000)]
Another round of planner/optimizer work. This is just restructuring and
code cleanup; no major improvements yet. However, EXPLAIN does produce
more intuitive outputs for nested loops with indexscans now...
Tom Lane [Sat, 8 Jan 2000 21:59:55 +0000 (21:59 +0000)]
Modify PageIsEmpty and PageGetMaxOffsetNumber macros to behave sanely
if presented an uninitialized (all zeroes) page. The system no longer
crashes hard if an all-zeroes page is present in a relation. There seem
to be some boundary conditions where a page will be appended to a relation
and zeroed, but its page header is never initialized; until we can track
down and fix all of those, robustness seems like a good idea.
Also, clean up some obsolete and downright wrong comments.
Bruce Momjian [Fri, 7 Jan 2000 17:22:47 +0000 (17:22 +0000)]
Sorry, that I send this letter/patch again, but previous sending is
still
without answer. I want continue with to_char(), but I need any answer
for this patch. Please.
Clean up format of tests.
Remove older "::" type coersion syntax in favor of extended SQL92 style.
Include a few new tests for datetime/timespan arithmetic.
Clean up syntax to use SQL92-ish type coersion
rather than the Postgres "::" notation.
All of these tests have been completely inspected and give correct results.
Repair two recently reported problems:
1) datetime_pl_span() added the seconds field before adding the months
field. This lead to erroneous results for e.g.
select datetime '1999-11-30' + timespan '1 mon - 1 sec';
Reverse the order of operations to add months first.
2) tm2timespan() did all intermediate math as integer, converting to double
at the very end. This resulted in hidden overflows when given very large
integer days, hours, etc. For example,
select '74565 days'::timespan;
produced the wrong result. Change code to ensure that doubles are used
for intermediate calculations.
Thanks to Olivier PRENANT <ohp@pyrenet.fr> and
Tulassay Zsolt <zsolt@tek.bke.hu> for problem reports and to Tom Lane for
accurate analyses.
Tom Lane [Fri, 31 Dec 1999 05:38:25 +0000 (05:38 +0000)]
Generate double-sided LIKE indexquals that work even in weird locales,
by continuing to increment the rightmost character until we get a string
that is demonstrably greater than the pattern prefix.
Tom Lane [Fri, 31 Dec 1999 03:41:03 +0000 (03:41 +0000)]
Clean up loose end in LIKE optimization fix: parser's code would generate
<= and >= indexquals from a LIKE even if the index in question didn't
support those operators. (As, for example, a hash index does not.)
Tom Lane [Thu, 30 Dec 1999 23:03:40 +0000 (23:03 +0000)]
elog() was set up to call abort() if it saw an ERROR or FATAL exit
during InitProcessingMode and the CurrentTransactionState was neither
TRANS_DEFAULT nor TRANS_DISABLED. Unfortunately, after someone's recent
change to start the transaction manager earlier in startup than it used
to be started, that caused an abort() and consequent database system
reset on quite harmless errors (such as rejecting an invalid user name!).
As far as I can see, the test on CurrentTransactionState was completely
useless anyway, so I've removed it.
Tom Lane [Thu, 30 Dec 1999 05:05:13 +0000 (05:05 +0000)]
Repair bugs discussed in pghackers thread of 15 May 1999: creation of a
relcache entry no longer leaks a small amount of memory. index_endscan
now releases all the memory acquired by index_beginscan, so callers of it
should NOT pfree the scan descriptor anymore.
Bruce Momjian [Mon, 27 Dec 1999 15:42:44 +0000 (15:42 +0000)]
Hi, all
I finally got around to schlepping through pg_dump, to finish what I started
about three months (or more) ago. Attached is a gzipped diff file to apply
in the bin/pg_dump directory. This should remove all string length
dependencies, except one, which I'm working on. It has been through some
rudimentary unit testing, but that's about it, so if any of you would give
it a more strenuous run-through, I'd be grateful for the feedback.
Tom Lane [Sun, 26 Dec 1999 03:48:22 +0000 (03:48 +0000)]
It turns out that the item size limit for btree indexes is about BLCKSZ/3,
not BLCKSZ/2 as some of us thought. Add check for oversize item so that
failure is detected before corrupting the index, not after.
Tom Lane [Fri, 24 Dec 1999 06:43:34 +0000 (06:43 +0000)]
Clean up handling of explicit NULL constants. Cases like
SELECT null::text;
SELECT int4fac(null);
work as expected now. In some cases a NULL must be surrounded by
parentheses:
SELECT 2 + null; fails
SELECT 2 + (null); OK
This is a grammatical ambiguity that seems difficult to avoid. Other
than that, NULLs seem to behave about like you'd expect. The internal
implementation is that NULL constants are typed as UNKNOWN (like
untyped string constants) until the parser can deduce the right type.
Tatsuo Ishii [Wed, 22 Dec 1999 04:12:55 +0000 (04:12 +0000)]
Add installation of pg_ctl
Locate path of postmaster in a portable way (stolen from initdb)
Add postmaster.opts.default.sample which should be copied into
$PGLIB in the installtion process. Also, it will be installed into
$PGDATA while initdb is running.
Bruce Momjian [Tue, 21 Dec 1999 17:42:16 +0000 (17:42 +0000)]
The first fix is to allow an input file with a relative path and without
a ".pgc " extension. The second patch fixes a coredump when there is
more than one input file (in that case, cur and types were not set to
NULL before processing the second f ile)
The patch below modifies the accepted grammar of ecpg to accept
FETCH [direction] [amount] cursor name
i.e. the IN|FROM clause becomes optional (as in Oracle and Informix).
This removes the incompatibility mentioned in section "Porting From
Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar
is modified in such a way as to avoid shift/reduce conflicts. It does
not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar
did (this seems to be a bug of the old grammar anyway).
This patch cleans up the handling of space characters in the scanner;
some patte rns require \n to be in {space}, some do not. A second fix is
the handling of cpp continuati on lines; the old pattern did not match
these. The parser is patched to fix an off-by-one error in the #line
directives. The pa rser is also enhanced to report the correct location
of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally,
some right recursions in the parser were replaced by left-recursions.
This patch adds preprocessor directives to ecpg; in particular
"EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and
defines, specified on the command line with -D. Defines, specified on
the command line are persistent across multiple input files. Defines can
be nested up to a maximum level of 128 (see patch). There is a fair
amount of error checking to make sure directives are matched properly. I
need preprocessor directives for porting code, that is written for an
Informix database, to a PostgreSQL database, while maintaining
compatibility with the original code. I decided not to extend the
already large ecpg grammar. Everything is done in the scanner by adding
some states, e.g. to skip all input except newlines and directives. The
preprocessor commands are compatible with Informix. Oracle uses a cpp
replacement.
Bruce Momjian [Tue, 21 Dec 1999 17:01:44 +0000 (17:01 +0000)]
This patch will avoid SIGFPE on some geo functions , if PostgreSQL is compiled
with DEC C.
DEC C doesn't handle double values greater than DBL_MAX, but some
PostgreSQL geo functions assign greater than DBL_MAX values to some vars
in some special cases - that couses SIGFPE. I dunno if that is the only place
to fix to work well with DEC C.
Tom Lane [Mon, 20 Dec 1999 02:15:35 +0000 (02:15 +0000)]
Finally found a platform which has finite() but nonetheless sets errno
rather than returning a NaN for bogus input to pow(). Namely, HPUX 10.20.
I think this is sufficient evidence for what I thought all along, which
is that the float.c code *must* look at errno whether finite() exists or
not.
Tom Lane [Mon, 20 Dec 1999 01:31:26 +0000 (01:31 +0000)]
Clean up some minor gcc warnings. I'm not touching the
major one, though, which is the truly ugly stores into libpq private
storage. Can't you find a better way to do this?
Tom Lane [Mon, 20 Dec 1999 00:51:25 +0000 (00:51 +0000)]
Avoid compiler warnings on systems that have snprintf and/or vsnprintf
but do not bother to declare them in <stdio.h>. Seems to be a more
common omission than you'd think...
Bruce Momjian [Sat, 18 Dec 1999 08:34:50 +0000 (08:34 +0000)]
> > It would be nice for new users; I think it would make it easier
> > for them to actually set out and do it. Many new users are
> > of the not-so-knowledgable variety, and shell scripting isn't
> > something they want to undertake.
>
> Can someone modify the vacuumdb shell script to do that?
i tried it... it seems to work
Jan Wieck [Fri, 17 Dec 1999 16:53:11 +0000 (16:53 +0000)]
Okay, this is how it looks: Please apply the attached patch to the current
sources, otherwise this whole things fails anyway (fails to create the
views).
Bruce Momjian [Fri, 17 Dec 1999 01:05:31 +0000 (01:05 +0000)]
This is my -- hopefully sufficiently portable -- attempt at cleaning out
initdb. No more obscure dependencies on environment variables or paths.
It
now finds the templates and the right postgres itself (with cmd line
options as fallback). It also no longer depends on $USER (su safe), and
doesn't advertise that --username allows you to install the db as a
different user, since that doesn't work anyway. Also, recovery and
cleanup
on all errors. Consistent options, clearer documentation.
Please take a look at this and adopt it if you feel it's safe enough. I
have simulated all the stupid circumstances I could think of, but you
never know with shell scripts.
Oh yeah, you can give the postgres user a default password now.