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.
Bruce Momjian [Thu, 16 Dec 1999 20:07:41 +0000 (20:07 +0000)]
>Turning nextval and currval into keywords is not an acceptable way to
>go about this. That will risk breaking existing applications that use
>those names as column names.
>
>It should actually almost work to write sq.nextval as things stand,
>because Postgres has for a long time considered table.function and
>function(table) to be interchangeable notations for certain kinds of
>functions. nextval doesn't seem to be one of that kind of function,
>at the moment. I'd suggest leaving the grammar as it was, and taking a
>look at ParseFuncOrColumn in parse_func.c to see if you can't persuade
>it to accept the sequence functions in that style.
OK, good point. I tried to implement it somewhere else and ended up
extending transformAttr. Attached you'll find the patch.
Bruce Momjian [Thu, 16 Dec 1999 17:24:19 +0000 (17:24 +0000)]
Here's the Create/Alter/Drop Group stuff that's been really overdue. I
didn't have time for documentation yet, but I'll write some. There are
still some things to work out what happens when you alter or drop users,
but the group stuff in and by itself is done.
Bruce Momjian [Thu, 16 Dec 1999 01:30:49 +0000 (01:30 +0000)]
Ethernet MAC addresses (macaddr type) are not compared correctly for
equality. The lobits macro is wrong and extracts the wrong set of
bits out of the structure.
To exhibit the problem:
select '000000:000000'::macaddr = '000000:110000'::macaddr ;
?column?
--------
t
(1 row)
Bruce Momjian [Thu, 16 Dec 1999 01:25:23 +0000 (01:25 +0000)]
I have done the QNX4 port with the current source tree. The number of
backend/Makefiles to be patched could significantly be reduced since
they
have been adopted to the QNX4 needs.
Bruce Momjian [Tue, 14 Dec 1999 00:08:21 +0000 (00:08 +0000)]
Depending on my interpreting (and programming) skills, this might solve
anywhere from zero to two TODO items.
* Allow flag to control COPY input/output of NULLs
I got this:
COPY table .... [ WITH NULL AS 'string' ]
which does what you'd expect. The default is \N, otherwise you can use
empty strings, etc. On Copy In this acts like a filter: every data item
that looks like 'string' becomes a NULL. Pretty straightforward.
This also seems to be related to
* Make postgres user have a password by default
If I recall this discussion correctly, the problem was actually that the
default password for the postgres (or any) user is in fact "\N", because
of the way copy is used. With this change, the file pg_pwd is copied out
with nulls as empty strings, so if someone doesn't have a password, the
password is just '', which one would expect from a new account. I don't
think anyone really wants a hard-coded default password.
Tom Lane [Mon, 13 Dec 1999 17:39:38 +0000 (17:39 +0000)]
Update documentation to reflect availability of aggregate(DISTINCT).
Try to provide a more lucid discussion in 'Using Aggregate Functions'
tutorial section.
Bruce Momjian [Sun, 12 Dec 1999 05:57:36 +0000 (05:57 +0000)]
I'm in TODO mood today ...
* Document/trigger/rule so changes to pg_shadow recreate pg_pwd
I did it with a trigger and it seems to work like a charm. The function
that already updates the file for create and alter user has been made a
built-in "SQL" function and a trigger is created at initdb time.
Comments around the pg_pwd updating function seem to be worried about
this
routine being called concurrently, but I really don't see a reason to
worry about this. Verify for yourself. I guess we never had a system
trigger before, so treat this with care, and feel free to adjust the
nomenclature as well.
Bruce Momjian [Sun, 12 Dec 1999 05:15:10 +0000 (05:15 +0000)]
Meanwhile, database names with single quotes in names don't work very well
at all, and because of shell quoting rules this can't be fixed, so I put
in error messages to that end.
Also, calling create or drop database in a transaction block is not so
good either, because the file system mysteriously refuses to roll back rm
calls on transaction aborts. :) So I put in checks to see if a transaction
is in progress and signal an error.
Also I put the whole call in a transaction of its own to be able to roll
back changes to pg_database in case the file system operations fail.
The alternative location issues I posted recently were untouched, awaiting
the outcome of that discussion. Other than that, this should be much more
fool-proof now.
Tom Lane [Fri, 10 Dec 1999 07:37:35 +0000 (07:37 +0000)]
Teach grammar and parser about aggregate(DISTINCT ...). No implementation
yet, but at least we can give a better error message:
regression=> select count(distinct f1) from int4_tbl;
ERROR: aggregate(DISTINCT ...) is not implemented yet
instead of 'parser: parse error at or near distinct'.
Bruce Momjian [Fri, 10 Dec 1999 03:59:30 +0000 (03:59 +0000)]
This should fix the \e (\p, \g, ...) behaviour on an empty query buffer.
Also, minor tweakage of tab completion, and I hope the output is flushed
on time now.
Tom Lane [Fri, 10 Dec 1999 03:01:05 +0000 (03:01 +0000)]
Correct coredump in ALTER TABLE foo ADD(). Accept explicit NULL in
typecasts, eg 'NULL::text'. Later parts of the parser don't like this
yet, but I'll work on that next.
Tom Lane [Thu, 9 Dec 1999 05:58:56 +0000 (05:58 +0000)]
Replace generic 'Illegal use of aggregates' error message with one that
shows the specific ungrouped variable being complained of. Perhaps this
will reduce user confusion...
Bruce Momjian [Thu, 9 Dec 1999 05:02:24 +0000 (05:02 +0000)]
Hi,
I was able to crash postgres 6.5.3 when I did an 'alter user' command.
After I started a debugger I found the problem in the timezone handling
of
datetime (my Linux box lost its timezone information, that's how the
problem occurred).
Only 7 bytes are reserved for the timezone, without checking for
boundaries.
Attached is a patch that fixes this problem and emits a NOTICE if a
timezone is encountered that is longer than MAXTZLEN bytes, like this:
Bruce Momjian [Tue, 7 Dec 1999 22:41:44 +0000 (22:41 +0000)]
Okay, that should put us back in sync. These two patches (src & doc) are
against the sources from one hour ago and contain all the portable and
up
to date stuff.
A few other CVS "householding" things you might want to take care of:
* Remove the src/bin/cleardbdir directory
* Remove the file src/bin/psql/sql_help.h from the repository, as it is
a derived file and is build by the release_prep.
Tom Lane [Tue, 7 Dec 1999 04:09:39 +0000 (04:09 +0000)]
Clean up memory leakage in find_inheritors() by using pg_list lists
(which are palloc'd) instead of DLLists (which are malloc'd). Not very
significant, since this routine seldom has anything useful to do, but
a leak is a leak...