- Prevent permissions on indexes
- Instituted --enable-multibyte option and tweaked the MB build process where necessary
- initdb prompts for superuser password
* Let unprivileged users change their own passwords.
* The password is now an Sconst in the parser, which better reflects its text datatype and also
forces users to quote them.
* If your password is NULL you won't be written to the password file, meaning you can't connect
until you have a password set up (if you use password authentication).
* When you drop a user that owns a database you get an error. The database is not gone.
choke on relation or attribute names containing spaces, quotes, or other
special characters. This fixes a TODO item. It also forces initdb,
since stored rule strings change.
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.
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.
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.
--
Peter Eisentraut Sernanders väg 10:115
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
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
* 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
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'.
