pgsql: Code review for dynahash change.

Code review for dynahash change. Commit be0a left behind a comment about the order of some tests that didn't make sense without the expensive division, and in fact we might as well change the order to one that fails more cheaply most of the time as a micro-optimization. Also, remove the "+ 1"

pgsql: Remove large fill factor support from dynahash.c.

Remove large fill factor support from dynahash.c. Since ancient times we have had support for a fill factor (maximum load factor) to be set for a dynahash hash table, but: 1. It was an integer, whereas for in-memory hash tables interesting load factor targets are probably somewhere near the 0.75

pgsql: Use factorial rather than numeric_fac in create_operator.sql.

Use factorial rather than numeric_fac in create_operator.sql. These two SQL functions are aliases for the same C function, so this change has no semantic effect. However, because we dropped the numeric_fac alias in HEAD (commit 76f412ab3), operator definitions based on that one don't port forward

pgsql: Use factorial rather than numeric_fac in create_operator.sql.

Use factorial rather than numeric_fac in create_operator.sql. These two SQL functions are aliases for the same C function, so this change has no semantic effect. However, because we dropped the numeric_fac alias in HEAD (commit 76f412ab3), operator definitions based on that one don't port forward

pgsql: Use factorial rather than numeric_fac in create_operator.sql.

Use factorial rather than numeric_fac in create_operator.sql. These two SQL functions are aliases for the same C function, so this change has no semantic effect. However, because we dropped the numeric_fac alias in HEAD (commit 76f412ab3), operator definitions based on that one don't port forward

pgsql: Use factorial rather than numeric_fac in create_operator.sql.

Use factorial rather than numeric_fac in create_operator.sql. These two SQL functions are aliases for the same C function, so this change has no semantic effect. However, because we dropped the numeric_fac alias in HEAD (commit 76f412ab3), operator definitions based on that one don't port forward

pgsql: Use factorial rather than numeric_fac in create_operator.sql.

Use factorial rather than numeric_fac in create_operator.sql. These two SQL functions are aliases for the same C function, so this change has no semantic effect. However, because we dropped the numeric_fac alias in HEAD (commit 76f412ab3), operator definitions based on that one don't port forward

pgsql: Use factorial rather than numeric_fac in create_operator.sql.

Use factorial rather than numeric_fac in create_operator.sql. These two SQL functions are aliases for the same C function, so this change has no semantic effect. However, because we dropped the numeric_fac alias in HEAD (commit 76f412ab3), operator definitions based on that one don't port forward

pgsql: Allow most keywords to be used as column labels without requirin

Allow most keywords to be used as column labels without requiring AS. Up to now, if you tried to omit "AS" before a column label in a SELECT list, it would only work if the column label was an IDENT, that is not any known keyword. This is rather unfriendly considering that we have so many keyword

pgsql: pg_surgery: Try to stabilize regression tests.

pg_surgery: Try to stabilize regression tests. According to buildfarm member sungazer, the behavior of VACUUM can be unstable in these tests even if we prevent autovacuum from running on the tables in question, apparently because even a manual vacuum can behave differently depending on whether any