required by the SQL standard, and TABLESPACE is useful functionality.
Patch from Kris Jurka, minor editorialization by Neil Conway.

pgcrypto crypt()/md5 and hmac() leak memory when compiled against
OpenSSL as openssl.c digest ->reset will do two DigestInit calls
against a context.  This happened to work with OpenSSL 0.9.6
but not with 0.9.7+.

Reason for the messy code was that I tried to avoid creating
wrapper structure to transport algorithm info and tried to use
OpenSSL context for it.  The fix is to create wrapper structure.

It also uses newer digest API to avoid memory allocations
on reset with newer OpenSSLs.

Thanks to Daniel Blaisdell for reporting it.

up a bunch of the support utilities.

In src/backend/utils/mb/Unicode remove nearly duplicate copies of the
UCS_to_XXX perl script and replace with one version to handle all generic
files.  Update the Makefile so that it knows about all the map files.
This produces a slight difference in some of the map files, using a
uniform naming convention and not mapping the null character.

In src/backend/utils/mb/conversion_procs create a master utf8<->win
codepage function like the ISO 8859 versions instead of having a separate
handler for each conversion.

There is an externally visible change in the name of the win1258 to utf8
conversion.  According to the documentation notes, it was named
incorrectly and this changes it to a standard name.

Running the Unicode mapping perl scripts has shown some additional mapping
changes in koi8r and iso8859-7.

is only used by scan.l/scan.c

64-bit platforms.

by ITAGAKI Takahiro

platforms (it does exist on HPUX, for one).  We could probably even make
this a test for specific AIX versions, but I don't know which ones need it.

Simon Riggs

we are not holding a buffer content lock; where it was, InterruptHoldoffCount
is positive and so we'd not respond to cancel signals as intended.  Also
add missing vacuum_delay_point() call in btvacuumcleanup.  This should fix
complaint from Evgeny Gridasov about failure to respond to SIGINT/SIGTERM
in a timely fashion (bug #2257).

inclusing SERIAL column sequences.

is set.

option state hasn't been fully set up.  This is possible via PQreset()
and might occur in other code paths too, so a state flag seems the
most robust solution.  Per report from Arturs Zoldners.

not just some of them.

don't promise more than the code actually delivers.

Var referencing the subselect output.  While this case could possibly be made
to work, it seems not worth expending effort on.  Per report from Magnus
Naeslund(f).

>
> 	o Allow pg_hba.conf to specify host names along with IP addresses
>
> 	  Host name lookup could occur when the postmaster reads the
> 	  pg_hba.conf file, or when the backend starts.  Another
> 	  solution would be to reverse lookup the connection IP and
> 	  check that hostname against the host names in pg_hba.conf.
> 	  We could also then check that the host name maps to the IP
> 	  address.

French uses "" for "don't want".  Seems we have to keep the existing
behavior.

id (CVE-2006-0553).  Also fix related bug in SET SESSION AUTHORIZATION that
allows unprivileged users to crash the server, if it has been compiled with
Asserts enabled.  The escalation-of-privilege risk exists only in 8.1.0-8.1.2.
However, the Assert-crash risk exists in all releases back to 7.3.
Thanks to Akio Ishida for reporting this problem.

Latin1, like we do for other Latin encodings.

Back out patch pending review.

---------------------------------------------------------------------------

>   I've now tested this patch at home w/ 8.2HEAD and it seems to fix the
>   bug.  I plan on testing it under 8.1.2 at work tommorow with
>   mod_auth_krb5, etc, and expect it'll work there.  Assuming all goes
>   well and unless someone objects I'll forward the patch to -patches.
>   It'd be great to have this fixed as it'll allow us to use Kerberos to
>   authenticate to phppgadmin and other web-based tools which use
>   Postgres.

  While playing with this patch under 8.1.2 at home I discovered a
  mistake in how I manually applied one of the hunks to fe-auth.c.
  Basically, the base code had changed and so the patch needed to be
  modified slightly.  This is because the code no longer either has a
  freeable pointer under 'name' or has 'name' as NULL.

  The attached patch correctly frees the string from pg_krb5_authname
  (where it had been strdup'd) if and only if pg_krb5_authname returned
  a string (as opposed to falling through and having name be set using
  name = pw->name;).  Also added a comment to this effect.
  Please review.

Stephen Frost (sfrost@snowman.net) wrote:

>   bug.  I plan on testing it under 8.1.2 at work tommorow with
>   mod_auth_krb5, etc, and expect it'll work there.  Assuming all goes
>   well and unless someone objects I'll forward the patch to -patches.
>   It'd be great to have this fixed as it'll allow us to use Kerberos to
>   authenticate to phppgadmin and other web-based tools which use
>   Postgres.

  While playing with this patch under 8.1.2 at home I discovered a
  mistake in how I manually applied one of the hunks to fe-auth.c.
  Basically, the base code had changed and so the patch needed to be
  modified slightly.  This is because the code no longer either has a
  freeable pointer under 'name' or has 'name' as NULL.

  The attached patch correctly frees the string from pg_krb5_authname
  (where it had been strdup'd) if and only if pg_krb5_authname returned
  a string (as opposed to falling through and having name be set using
  name = pw->name;).  Also added a comment to this effect.
  Please review.

Stephen Frost (sfrost@snowman.net) wrote:

report from French Debian user.  psql already handles "" fine.

> True, but they're not being used where you'd expect. This seems to be
> something to do with the fact that it's not pg_authid which is being
> accessed, but rather the view pg_roles.

I looked into this and it seems the problem is that the view doesn't
get flattened into the main query because of the has_nullable_targetlist
limitation in prepjointree.c.  That's triggered because pg_roles has
        '********'::text AS rolpassword
which isn't nullable, meaning it would produce wrong behavior if
referenced above the outer join.

Ultimately, the reason this is a problem is that the planner deals only
in simple Vars while processing joins; it doesn't want to think about
expressions.  I'm starting to think that it may be time to fix this,
because I've run into several related restrictions lately, but it seems
like a nontrivial project.

In the meantime, reducing the LEFT JOIN to pg_roles to a JOIN as per
Peter's suggestion seems like the best short-term workaround.

Joshua D. Drake

> 	o %Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME

Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME

Joachim Wieland

default"
> or "NO SCROLL is the default", it will be rejected as incorrect.  The
> reason is that the default behavior is different from either of these,
> as is explained in the NOTES section.

Ok, so *that's* where the bit about the query plan being simple enough.
Based on that, ISTM that it should be premissable for us to decide that
a cursor requiring a sort isn't "simple enough" to support SCROLL.

In any case, here's a patch that makes the non-standard behavior easier
for people to find.

Jim C. Nasby