> > 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

neko@kredit.sth.sz

sources, otherwise this whole things fails anyway (fails to create the
views).

Peter Eisentraut

Manually applied - Jan

 Somehow got bracketed with #ifdef NOT_USED instead.

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

keeping parenlevel unchanged.

Jan

I sending promised patch with:

        * getopt_long() - for pg_dump (portable)

        * and "Usage: " changes in scripts in src/bin/
          - this changes are cosmetic only, not change any
          feature ...etc.

 All PostgreSQL routines (scripts) support now long options and
help's output is alike for all scripts and all support -? or --help.

                                                Karel

Karel Zak <zakkr@zf.jcu.cz>              http://home.zf.jcu.cz/~zakkr/

>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

This patch solves a couple of memory leaks in ecpglib.c.  The patch is
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

Try to provide a more lucid discussion in 'Using Aggregate Functions'
tutorial section.

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