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.

Kirill Nosov.

in regression tests.

Jan

Jan

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.

major one, though, which is the truly ugly stores into libpq private
storage.  Can't you find a better way to do this?

what a header file is for :-(

but do not bother to declare them in <stdio.h>.  Seems to be a more
common omission than you'd think...

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