| Age | Commit message (Collapse) | Author |
|---|
|
>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.
Jeroen van Vianen
|
|
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.
--
Peter Eisentraut Sernanders väg 10:115
|
|
|
|
|
|
|
|
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)
Daniel Boyd
|
|
backend/Makefiles to be patched could significantly be reduced since
they
have been adopted to the QNX4 needs.
Andreas Kardos
|
|
ok for both the
development tree (CVS) and for 6.5.3.
Stephen Birch
|
|
trees. Also rewrite find_all_inheritors() in a more intelligible style.
|
|
triggered
> function now returns the right datatype.
Oops, I got crossed up with Jan's improvements. Ignore this.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
|
|
triggered
function now returns the right datatype.
--
Peter Eisentraut Sernanders väg 10:115
|
|
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.
Peter Eisentraut Sernanders väg 10:115
|
|
|
|
|
|
Note this forces initdb because of change of Aggref node in stored rules.
|
|
|
|
* 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.
--
Peter Eisentraut Sernanders väg 10:115
|
|
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.
The docs I cleaned up as well.
Peter Eisentraut Sernanders väg 10:115
|
|
|
|
|
|
* pg_dump should preserve primary key information
Also a couple of warnings removed.
--
Peter Eisentraut Sernanders väg 10:115
|
|
|
|
|
|
|
|
time qualification of HeapTupleSatisfiesSnapshot()
Jan
|
|
|
|
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'.
|
|
|
|
|
|
Also, minor tweakage of tab completion, and I hope the output is flushed
on time now.
--
Peter Eisentraut Sernanders väg 10:115
|
|
|
|
typecasts, eg 'NULL::text'. Later parts of the parser don't like this
yet, but I'll work on that next.
|
|
|
|
multisession test tool.
Jan
|
|
|
|
|
|
shows the specific ungrouped variable being complained of. Perhaps this
will reduce user confusion...
|
|
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:
Jeroen van Vianen
|
|
|
|
Jan
|
|
|
|
|
|
|
|
|
|
|
|
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.
Peter Eisentraut
|
|
|
|
(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...
|
|
Jan
|
|
Jan
|
