validate and display correctly.

<
< * psql tab completion
<
< 	o Provide a list of conversions after ALTER CONVERSION?
< 	o Support for ALTER SEQUENCE clauses
< 	o Add RENAME TO to ALTER TRIGGER
< 	o Support for ALTER USER
< 	o Fix ALTER (GROUP|DOMAIN|...) <sth> DROP
< 	o Support for ALTER LANGUAGE <sth> RENAME TO
< 	o Improve support for COPY
< 	o Improve support for ALTER TABLE

<   heap page to find matching rows.
>   heap page to find matching rows, or perhaps use a mixed solution where
>   tids are recorded for pages with only a few matches and per-page bitmaps
>   are used for more dense pages.  Another idea is to use a 32-bit bitmap
>   for every page and set a bit based on the item number mod(32).

selectivity estimates, per recent discussion.

shared memory segment ID.  If we can't access the existing shmem segment,
it must not be relevant to our data directory.  If we can access it,
then attach to it and check for an actual match to the data directory.
This should avoid some cases of failure-to-restart-after-boot without
introducing any significant risk of failing to detect a still-running
old backend.

>
> * Research the use of larger pages sizes

malloc() doesn't set errno, so most uses were buggy anyway.

<   Such indexes could be more compact if there are only a few unique values.
>   Such indexes could be more compact if there are only a few distinct values.
>   Such indexes can also be compressed.  Keeping such indexes updated can be
>   costly.

from Alvaro Herrera.

warnings:

- remove pointless "extern" keyword from some function definitions in
contrib/tsearch2

- use "NULL" not "0" as NULL pointer in contrib/tsearch,
contrib/tsearch2, contrib/pgbench, and contrib/vacuumlo

<   Such indexes could be more compact if there are few unique value.
>   Such indexes could be more compact if there are only a few unique values.

<   portability issues. Anonymous mmap is required to prevent I/O
<   overhead.
>   portability issues. Anonymous mmap (or mmap to /dev/zero) is required
>   to prevent I/O overhead.
>
> * Consider mmap()'ing files into a backend?
>
>   Doing I/O to large tables would consume a lot of address space or
>   require frequent mapping/unmapping.  Extending the file also causes
>   mapping problems that might require mapping only individual pages,
>   leading to thousands of mappings.  Another problem is that there is no
>   way to _prevent_ I/O to disk from the dirty shared buffers so changes
>   could hit disk before WAL is written.

estimates when combining the estimates for a range query.  As pointed out
by Miquel van Smoorenburg, the existing check for an impossible combined
result would quite possibly fail to detect one default and one non-default
input.  It seems better to use the default range query estimate in such
cases.  To do so, add a check for an estimate of exactly DEFAULT_INEQ_SEL.
This is a bit ugly because it introduces additional coupling between
clauselist_selectivity and scalarltsel/scalargtsel, but it's not like
there wasn't plenty already...

<   posix_fadvise() [fadvise]
>   posix_fadvise()
>
>   Posix_fadvise() can control both sequential/random file caching and
>   free-behind behavior, but it is unclear how the setting affects other
>   backends that also have the file open, and the feature is not supported
>   on all operating systems.
>

Add explicit documentation of the recovery configuration settings.  Other
minor improvements in the PITR docs.  Simon Riggs, some editorialization
by Tom Lane.

< * CREATE TABLE AS can not determine column lengths from expressions [atttypmod]
> * Allow CREATE TABLE AS to determine column lengths for complex
>   expressions like SELECT col1 || col2

< * Automatically create rules on views so they are updateable, per SQL99 [view]
> * Automatically create rules on views so they are updateable, per SQL99
>
>   We can only auto-create rules for simple views.  For more complex
>   cases users will still have to write rules.
>

than erroring out.  This is the Unix behavior.

working as intended --- for some reason, FROM a.b.c was getting
parsed as if it were a function name and not a qualified name.
I think there must be a bug in bison, because it should have
complained that the grammar was ambiguous.  Anyway, fix it along
the same lines previously used for func_name vs columnref, and get
rid of the right-recursion in attrs that seems to have confused
bison.