days.  It seems to be a FAQ, and I think I know why. When creating a 'c'
language function, CREATE FUNCTION is fed the shared object filename,
and seems to succeed. Only when trying to use the function is an error
thrown, by which time the coder thinks something's wrong with executing
the code, not with loading it.

I think I once saw it proposed to load shared objects at function creation
time, but that idea was shot down on the grounds of resident memory bloat,
ISTR. Here's a patch for a compromise: all it does is stat() the file,
just like the loader code does, so that the errors caused by non existent
files, and no directory 'x' permissions (the most common ones, it seems),
get caught while the developer is still thinking about code loading. It
doesn't catch all errors (like the code not being readable by the postgres
user) but seems to catch the most common, without actually opening the file.

What do you think?

Ross

indexes, apparently, nor on functional indexes with more than one input
column (force of natts = 1 was in the wrong branch of IF statement).
Coredumped if source relation contained any uncommitted tuples, due to
failure to test for success return from heap_fetch.  Fetched tuple
was passed directly to heap_insert, which clobbers the TID and commit
status in the tuple header it's given, which meant that the source
relation's tuples all got trashed as the copy proceeded.  Abort partway
through, and you're left with a lot of missing tuples.
I wonder what else is lurking here ...

this fixes the bug where setting the entry in he process table no longer works
under FreeBSD ... basically, if setproctitle() exists, use it ...

the draw back right now is the PS_SET_STATUS stuff doesn't work, but am looking
into that one right now ... at lesat now you can see who is connecting where
and from where ...

Add two checks ... one for setproctitle and one for -lutil ...

Don't do anything with them at this time, but am working on that ...

Make it behave correctly when there are more than two tables being
joined, also.  Update regression test expected outputs.

 Reported by Adrian Oboroc <aoboroc@btr.md>.

mappings.  In fact, it had them backward because it was using the 6.5.*
code.  Copied them from parser/gram.y, so it is fixed now.  Looks like
our first 7.0.1 fix.  Oops, seems Tom has beat me to it as I was typing
this.

It's still pretty fundamentally bogus :-(.
Freebie side benefit: ALTER TABLE RENAME works on indexes now.

loading new data, for consistency with its handling of pg_shadow.

Thanks
Andreas

to need this updatepgproc.sql script after all...

Rearrange handling of VACUUMs so that they are certain to be executed
as superuser not some random user; also, do not forget to vacuum
template1 itself.