
For Immediate Release				February 5th, 2002

	After almost a full year of development since PostgreSQL v7.1 was
released, the PostgreSQL Global Development Group is proud to announce the
availability of our latest development milestone ... PostgreSQL v7.2,
another step forward for the project.

	A full list of changes to v7.2 can be found in the HISTORY file,
included with the release, as well as under all ftp mirrors as:

		/pub/README.v7_2

	Highlights of this release are as follows:

   VACUUM
           Vacuuming no longer locks tables, thus allowing normal user
           access during the vacuum. A new "VACUUM FULL" command does
           old-style vacuum by locking the table and shrinking the on-disk
           copy of the table.

   Transactions
           There is no longer a problem with installations that exceed
           four billion transactions.

   OID's
           OID's are now optional. Users can now create tables without
           OID's for cases where OID usage is excessive.

   Optimizer
           The system now computes histogram column statistics during
           "ANALYZE", allowing much better optimizer choices.

   Security
           A new MD5 encryption option allows more secure storage and
           transfer of passwords. A new Unix-domain socket authentication
           option is available on Linux and BSD systems.

   Statistics
           Administrators can use the new table access statistics module
           to get fine-grained information about table and index usage.

   Internationalization
           Program and library messages can now be displayed in several
           languages.

	.. with many many more bug fixes, enhancements and performance
related changes ...

	Source for this release is available on all mirrors under:

		/pub/source/v7.2

	As always, any bugs with this release should be reported to
pgsql-bugs@postgresql.org ... and, as with all point releases, this
release requires a complete dump and reload from previous releases, due to
internal structure changes ...

Marc G. Fournier
Co-ordinator
PostgreSQL Global Development Group





Tue, 5 Feb 2002 12:01:24 -0400 (AST)
"Marc G. Fournier" <scrappy@postgresql.org>
PostgreSQL v7.2 Final Release
"Marc G. Fournier" <scrappy@postgresql.org> writes:

> For Immediate Release				February 5th, 2002
> 
> 	After almost a full year of development since PostgreSQL v7.1 was
> released, the PostgreSQL Global Development Group is proud to announce the
> availability of our latest development milestone ... PostgreSQL v7.2,
> another step forward for the project.

RPMs for Red Hat Linux 7.2 can be found at http://people.redhat.com/teg/pg/

-- 
Trond Eivind Glomsrï¿½d
Red Hat, Inc.

05 Feb 2002 11:15:17 -0500
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: PostgreSQL v7.2 Final Release
On Tue, 2002-02-05 at 18:15, Trond Eivind Glomsrï¿½d wrote:
> "Marc G. Fournier" <scrappy@postgresql.org> writes:
> 
> > For Immediate Release				February 5th, 2002
> > 
> > 	After almost a full year of development since PostgreSQL v7.1 was
> > released, the PostgreSQL Global Development Group is proud to announce the
> > availability of our latest development milestone ... PostgreSQL v7.2,
> > another step forward for the project.
> 
> RPMs for Red Hat Linux 7.2 can be found at http://people.redhat.com/teg/pg/

Why is just plperl included ?

What about pl/python and pl/tcl (I hope pl/pgsql is there somewhere) ?

--------------
Hannu



05 Feb 2002 19:07:54 +0200
Hannu Krosing <hannu@tm.ee>
Re: PostgreSQL v7.2 Final Release
Hannu Krosing <hannu@tm.ee> writes:

> On Tue, 2002-02-05 at 18:15, Trond Eivind Glomsrï¿½d wrote:
> > "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > 
> > > For Immediate Release				February 5th, 2002
> > > 
> > > 	After almost a full year of development since PostgreSQL v7.1 was
> > > released, the PostgreSQL Global Development Group is proud to announce the
> > > availability of our latest development milestone ... PostgreSQL v7.2,
> > > another step forward for the project.
> > 
> > RPMs for Red Hat Linux 7.2 can be found at http://people.redhat.com/teg/pg/
> 
> Why is just plperl included ?
> 
> What about pl/python

There is no shared python library. Linking in static libraries in
dynamic extensions doesn't work on most platforms.

> and pl/tcl (I hope pl/pgsql is there somewhere) ?

The postgresql-tcl package contains that, FTTB, but tcl is pretty much
dead anyway...
-- 
Trond Eivind Glomsrï¿½d
Red Hat, Inc.

05 Feb 2002 12:11:08 -0500
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: [HACKERS] PostgreSQL v7.2 Final Release
On Tuesday 05 February 2002 12:07 pm, Hannu Krosing wrote:
> Why is just plperl included ?

> What about pl/python and pl/tcl (I hope pl/pgsql is there somewhere) ?

pl/pgsql is in the base server package.
pl/tcl is in the tcl subpackage, although that might not be a good thing.

What is required to build pl/python?  Last I heard is was halfway 
experimental?
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 5 Feb 2002 12:33:01 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] PostgreSQL v7.2 Final Release
On Tuesday 05 February 2002 12:11 pm, Trond Eivind Glomsrï¿½d wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > What about pl/python

> There is no shared python library. Linking in static libraries in
> dynamic extensions doesn't work on most platforms.

That's what I thought, but wasn't sure.

Oh, I'm building NLS-capable RPM's as I write this; expect an upload shortly. 
The NLS file list mechanism munged the execute permission for the initscript, 
so I had to track that down before release.  Hopefully this last build will 
have the right perms.

I even have the release announcement composed in kmail waiting for a fully 
successful build.....
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 5 Feb 2002 12:37:29 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] PostgreSQL v7.2 Final Release
On Tue, 5 Feb 2002, Lamar Owen wrote:

> On Tuesday 05 February 2002 12:11 pm, Trond Eivind Glomsrï¿½d wrote:
> > Hannu Krosing <hannu@tm.ee> writes:
> > > What about pl/python
> 
> > There is no shared python library. Linking in static libraries in
> > dynamic extensions doesn't work on most platforms.
> 
> That's what I thought, but wasn't sure.

FWIW, the python rpms in Rawhide have static libraries, but are compiled 
with -fPIC. Thus, they can actually be used in this way...

> Oh, I'm building NLS-capable RPM's as I write this; expect an upload shortly. 
> The NLS file list mechanism munged the execute permission for the initscript, 
> so I had to track that down before release.  Hopefully this last build will 
> have the right perms.

I need to sync up after that, before I do some more fixes to the 
initscript.


-- 
Trond Eivind Glomsrï¿½d
Red Hat, Inc.


Tue, 5 Feb 2002 12:39:28 -0500 (EST)
=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= <teg@redhat.com>
Re: [HACKERS] PostgreSQL v7.2 Final Release
* Marc G. Fournier <scrappy@postgresql.org> [020205 11:10]:
> 
> For Immediate Release				February 5th, 2002
> 
> 	After almost a full year of development since PostgreSQL v7.1 was
> released, the PostgreSQL Global Development Group is proud to announce the
> availability of our latest development milestone ... PostgreSQL v7.2,
> another step forward for the project.

Woo hoo!

Can I start putting changes into the PyGreSQL module or do we want to
give it a few days to shake the immediate bugs out?

Kudos all around, btw.  This looks like a really nice release.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Tue, 5 Feb 2002 12:44:54 -0500
"D'Arcy J.M. Cain" <darcy@druid.net>
Re: PostgreSQL v7.2 Final Release
On Tue, 2002-02-05 at 19:11, Trond Eivind Glomsrï¿½d wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> 
> > On Tue, 2002-02-05 at 18:15, Trond Eivind Glomsrï¿½d wrote:
> > > "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > > 
> > > > For Immediate Release				February 5th, 2002
> > > > 
> > > > 	After almost a full year of development since PostgreSQL v7.1 was
> > > > released, the PostgreSQL Global Development Group is proud to announce the
> > > > availability of our latest development milestone ... PostgreSQL v7.2,
> > > > another step forward for the project.
> > > 
> > > RPMs for Red Hat Linux 7.2 can be found at http://people.redhat.com/teg/pg/
> > 
> > Why is just plperl included ?
> > 
> > What about pl/python
> 
> There is no shared python library. Linking in static libraries in
> dynamic extensions doesn't work on most platforms.

Does that mean that one can't run pl/python on Redhat 7.2 ??

I was hoping that all the work that went into fixing various flaws in
pl/python during 7.2 development would result in it being available in
binary distributions too...

-----------------
Hannu



05 Feb 2002 19:47:04 +0200
Hannu Krosing <hannu@tm.ee>
Re: PostgreSQL v7.2 Final Release
On 5 Feb 2002, Hannu Krosing wrote:

> On Tue, 2002-02-05 at 19:11, Trond Eivind Glomsrï¿½d wrote:
> > Hannu Krosing <hannu@tm.ee> writes:
> > 
> > > On Tue, 2002-02-05 at 18:15, Trond Eivind Glomsrï¿½d wrote:
> > > > "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > > > 
> > > > > For Immediate Release				February 5th, 2002
> > > > > 
> > > > > 	After almost a full year of development since PostgreSQL v7.1 was
> > > > > released, the PostgreSQL Global Development Group is proud to announce the
> > > > > availability of our latest development milestone ... PostgreSQL v7.2,
> > > > > another step forward for the project.
> > > > 
> > > > RPMs for Red Hat Linux 7.2 can be found at http://people.redhat.com/teg/pg/
> > > 
> > > Why is just plperl included ?
> > > 
> > > What about pl/python
> > 
> > There is no shared python library. Linking in static libraries in
> > dynamic extensions doesn't work on most platforms.
> 
> Does that mean that one can't run pl/python on Redhat 7.2 ??

On IA32, it will work (with a performance penalty, "thou shall not use 
static libraries in dynamic extensions"), on other archs (alpha, IA64, 
S/390) it will die.

-- 
Trond Eivind Glomsrï¿½d
Red Hat, Inc.


Tue, 5 Feb 2002 12:51:59 -0500 (EST)
=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= <teg@redhat.com>
Re: [HACKERS] PostgreSQL v7.2 Final Release
On Tue, 2002-02-05 at 18:11, Trond Eivind Glomsrï¿½d wrote:

> The postgresql-tcl package contains that, FTTB, but tcl is pretty much
> dead anyway...

So all of us who have been using tcl for years and are comfortable with
it should just forget about it maybe? Tcl the best kept secret of the
internet...

Cheers

Tony Grant

-- 
RedHat Linux on Sony Vaio C1XD/S
http://www.animaproductions.com/linux2.html
Macromedia UltraDev with PostgreSQL
http://www.animaproductions.com/ultra.html


05 Feb 2002 19:20:41 +0100
tony <tony@animaproductions.com>
Re: [HACKERS] PostgreSQL v7.2 Final Release
On Tue, 2002-02-05 at 19:51, Trond Eivind Glomsrï¿½d wrote:
> On 5 Feb 2002, Hannu Krosing wrote:
> 
> > On Tue, 2002-02-05 at 19:11, Trond Eivind Glomsrï¿½d wrote:
> > > Hannu Krosing <hannu@tm.ee> writes:
> > > 
> > > > On Tue, 2002-02-05 at 18:15, Trond Eivind Glomsrï¿½d wrote:
> > > > > "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > > > > 
> > > > > > For Immediate Release				February 5th, 2002
> > > > > > 
> > > > > > 	After almost a full year of development since PostgreSQL v7.1 was
> > > > > > released, the PostgreSQL Global Development Group is proud to announce the
> > > > > > availability of our latest development milestone ... PostgreSQL v7.2,
> > > > > > another step forward for the project.
> > > > > 
> > > > > RPMs for Red Hat Linux 7.2 can be found at http://people.redhat.com/teg/pg/
> > > > 
> > > > Why is just plperl included ?
> > > > 
> > > > What about pl/python
> > > 
> > > There is no shared python library. Linking in static libraries in
> > > dynamic extensions doesn't work on most platforms.
> > 
> > Does that mean that one can't run pl/python on Redhat 7.2 ??
> 
> On IA32, it will work (with a performance penalty, "thou shall not use 
> static libraries in dynamic extensions"),

Any estimate how big the penalty is ? 

Also is it just a load-time penalty or continuous ?

-------------
Hannu



05 Feb 2002 20:21:37 +0200
Hannu Krosing <hannu@tm.ee>
Re: PostgreSQL v7.2 Final Release
"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> Can I start putting changes into the PyGreSQL module or do we want to
> give it a few days to shake the immediate bugs out?

Don't check in any 7.3 development until we split off a CVS branch for
7.2 maintenance.  We'll probably wait at least a week before we do that;
longer if it looks like there are lots of problems...

			regards, tom lane

Tue, 05 Feb 2002 13:24:03 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PostgreSQL v7.2 Final Release 

> There is no shared python library. Linking in static libraries in
> dynamic extensions doesn't work on most platforms.
> 
> > and pl/tcl (I hope pl/pgsql is there somewhere) ?
> 
> The postgresql-tcl package contains that, FTTB, but tcl is pretty much
> dead anyway...

Please refrain from language flames...the pgsql lists are exceptional
lists that really don't need this pollution.

thanks,

	--brett

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Tue, 5 Feb 2002 11:15:30 -0800
Brett Schwarz <brett_schwarz@yahoo.com>
Re: [HACKERS] PostgreSQL v7.2 Final Release
>>>>> "Trond" == Trond Eivind Glomsrï¿½d <teg@redhat.com> writes:

>> > There is no shared python library. Linking in static libraries in
>> > dynamic extensions doesn't work on most platforms.
>> 
>> Does that mean that one can't run pl/python on Redhat 7.2 ??

Trond> On IA32, it will work (with a performance penalty, "thou shall not use 
Trond> static libraries in dynamic extensions"), on other archs (alpha, IA64, 
Trond> S/390) it will die.

On Darwin, linking a static libperl.a works just fine, although it
creates a libperl.dynlib, which I had to symlink to libperl.so to get
it to load.

Woo hoo.  Embedded Perl.  On #perl, we were already discussing having
a Pg process put up a web-socket, or proxy through to another database
with DBI.  OK, we're crazy.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

05 Feb 2002 12:11:17 -0800
merlyn@stonehenge.com (Randal L. Schwartz)
Re: [HACKERS] PostgreSQL v7.2 Final Release
teg@redhat.com (Trond Eivind Glomsrï¿½d) writes:
> ... but tcl is pretty much dead anyway...

You have no idea how wrong you are.
-- 
matthew rice <matt@starnix.com>                               starnix inc.
phone: 905-771-0017                             thornhill, ontario, canada
http://www.starnix.com              professional linux services & products

05 Feb 2002 18:53:30 -0500
Matthew Rice <matt@starnix.com>
Re: [HACKERS] PostgreSQL v7.2 Final Release
Marc G. Fournier writes:

> 	After almost a full year of development since PostgreSQL v7.1 was
> released, the PostgreSQL Global Development Group is proud to announce the
> availability of our latest development milestone ... PostgreSQL v7.2,
> another step forward for the project.

Are you going to put some announcements on web sites such as freshmeat,
linuxpr, bsdtoday?

-- 
Peter Eisentraut   peter_e@gmx.net


Tue, 5 Feb 2002 22:34:10 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: PostgreSQL v7.2 Final Release

working through those today ...

On Tue, 5 Feb 2002, Peter Eisentraut wrote:

> Marc G. Fournier writes:
>
> > 	After almost a full year of development since PostgreSQL v7.1 was
> > released, the PostgreSQL Global Development Group is proud to announce the
> > availability of our latest development milestone ... PostgreSQL v7.2,
> > another step forward for the project.
>
> Are you going to put some announcements on web sites such as freshmeat,
> linuxpr, bsdtoday?
>
> --
> Peter Eisentraut   peter_e@gmx.net
>
>


Wed, 6 Feb 2002 09:07:19 -0400 (AST)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: PostgreSQL v7.2 Final Release
[after delays....]
On Tuesday 05 February 2002 11:01 am, Marc G. Fournier wrote:
> 	Source for this release is available on all mirrors under:

> 		/pub/source/v7.2

RPMs for PostgreSQL 7.2 available as soon as the mirrors propagate in 
/pub/binary/v7.2/RPMS

BIG NOTE:
Due to RPM's versioning scheme, and my unwillingness to further obfuscate the 
versioning with Epoch or Serial tags, if you have be running the beta or 
release candidate RPMs of 7.2 you will need to use the '--oldpackage' switch 
to the rpm command line.

Please read the README.rpm-dist and CHANGELOG files in the above referenced 
directory for more information.

Bug reports to either pgsql-bugs or pgsql-ports, please.

RPMs for redhat-6.2 will be available shortly.  Note that you may need to 
update OS utilities to rebuild from source on Red Hat 6.2.  An updated patch 
utility is known to be necessary.

Sorry for the delay in getting these posted -- I had them built yesterday 
morning, but couldn't upload to ftp.postgresql.org dueto some server problem 
there.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Wed, 6 Feb 2002 09:36:45 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: PostgreSQL v7.2 Final Release
Brett Schwarz wrote:
> 
> > There is no shared python library. Linking in static libraries in
> > dynamic extensions doesn't work on most platforms.
> >
> > > and pl/tcl (I hope pl/pgsql is there somewhere) ?
> >
> > The postgresql-tcl package contains that, FTTB, but tcl is pretty much
> > dead anyway...
> 
> Please refrain from language flames...the pgsql lists are exceptional
> lists that really don't need this pollution.
>

You think language flames are bad? Try the perennial GPL vs BSD flame.
Every few months or so we have a storm of hundreds of posts proclaiming
the merits of GPL or BSD. A language debate would be mild by comparison.

Wed, 06 Feb 2002 15:15:55 -0500
mlw <markw@mohawksoft.com>
Re: [GENERAL] PostgreSQL v7.2 Final Release
On Wednesday 06 February 2002 09:36 am, Lamar Owen wrote:
> RPMs for PostgreSQL 7.2 available as soon as the mirrors propagate in
> /pub/binary/v7.2/RPMS

> RPMs for redhat-6.2 will be available shortly.  Note that you may need to
> update OS utilities to rebuild from source on Red Hat 6.2.  An updated
> patch utility is known to be necessary.

Thanks to Dr. Rich Shepard, we have Red Hat 6.2 binary RPMs, built for i386, 
i586, and i686 architectures.  If there is demand, I will attempt a build for 
SuSE 7.3 on UltraSPARC.  I also am looking at Caldera builds (thanks to Larry 
Rosenman).  Mandrake 8.0 RPMs should be built shortly, thanks to Justin Clift.

Thomas Lockhart typically does Mandrake 7.2.  For Thomas and other PostgreSQL 
developers who are members of the pgsql group on the dev server, the dirs are 
g+w for the binaries.

Exciting times!
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Wed, 6 Feb 2002 19:48:13 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] PostgreSQL v7.2 Final Release
On Wed, 6 Feb 2002, Lamar Owen wrote:

> Thanks to Dr. Rich Shepard, we have Red Hat 6.2 binary RPMs, built for i386, 
> i586, and i686 architectures.

  I found that in order to rebuild the 7.2.src.rpm I had to upgrade my
'patch' utility. The one I had installed was version 2.5-9 (the package
build); the one I built from the .src.rpm is 2.5.4. As soon as I freshened
the installation, the command 'rpm --rebuild ...' worked just fine.

  However, there's a problem with 'gettext' that I didn't resolve.
Apparently RH 6.2's version is too old, but trying to rebuild the
gettext.src.rpm kept failing. Rather than futz with that, too, I changed the
spec file so !nls = 0} and I commented out the line requiring gettext.

  If you do this, you need to rebuild the packages from the
/usr/src/redhat/SPECS/ directory with the command, 'rpm -ba [--target=iX86]
...'. However, the full set of binary packages for i386, i586, and i686 are
on the postgres ftp server. The i686 version freshened our installation from
7.1.3 to 7.2 flawlessly.

Glad to contribute,

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                         http://www.appl-ecosys.com


Wed, 6 Feb 2002 17:13:44 -0800 (PST)
Rich Shepard <rshepard@appl-ecosys.com>
Re: [HACKERS] PostgreSQL v7.2 Final Release
Thank you!

----- Original Message -----
From: "Marc G. Fournier" <scrappy@postgresql.org>
To: <pgsql-announce@postgresql.org>
Cc: <pgsql-hackers@postgresql.org>; <pgsql-general@postgresql.org>
Sent: Tuesday, February 05, 2002 11:01 AM
Subject: PostgreSQL v7.2 Final Release


>
> For Immediate Release February 5th, 2002
>
> After almost a full year of development since PostgreSQL v7.1 was
> released, the PostgreSQL Global Development Group is proud to announce the
> availability of our latest development milestone ... PostgreSQL v7.2,
> another step forward for the project.
>
> A full list of changes to v7.2 can be found in the HISTORY file,
> included with the release, as well as under all ftp mirrors as:
>
> /pub/README.v7_2
>
> Highlights of this release are as follows:
>
>    VACUUM
>            Vacuuming no longer locks tables, thus allowing normal user
>            access during the vacuum. A new "VACUUM FULL" command does
>            old-style vacuum by locking the table and shrinking the on-disk
>            copy of the table.
>
>    Transactions
>            There is no longer a problem with installations that exceed
>            four billion transactions.
>
>    OID's
>            OID's are now optional. Users can now create tables without
>            OID's for cases where OID usage is excessive.
>
>    Optimizer
>            The system now computes histogram column statistics during
>            "ANALYZE", allowing much better optimizer choices.
>
>    Security
>            A new MD5 encryption option allows more secure storage and
>            transfer of passwords. A new Unix-domain socket authentication
>            option is available on Linux and BSD systems.
>
>    Statistics
>            Administrators can use the new table access statistics module
>            to get fine-grained information about table and index usage.
>
>    Internationalization
>            Program and library messages can now be displayed in several
>            languages.
>
> .. with many many more bug fixes, enhancements and performance
> related changes ...
>
> Source for this release is available on all mirrors under:
>
> /pub/source/v7.2
>
> As always, any bugs with this release should be reported to
> pgsql-bugs@postgresql.org ... and, as with all point releases, this
> release requires a complete dump and reload from previous releases, due to
> internal structure changes ...
>
> Marc G. Fournier
> Co-ordinator
> PostgreSQL Global Development Group
>
>
>
>
>


Wed, 6 Feb 2002 22:04:22 -0500
"Rob Arnold" <rob@cabrion.com>
Re: PostgreSQL v7.2 Final Release
Quoting "Marc G. Fournier" <scrappy@postgresql.org>:

> For Immediate Release				February 5th, 2002
> 
>    Security
>            A new MD5 encryption option allows more secure storage and
>            transfer of passwords. A new Unix-domain socket authentication
>            option is available on Linux and BSD systems.

First question:

        Is this backport(-able/-ed) to 7.1.3?

Second question:

        Is 7.2 ready for production?

07 Feb 2002 16:04:23 +0100
Turbo Fredriksson <turbo@bayour.com>
Re: PostgreSQL v7.2 Final Release
Turbo Fredriksson <turbo@bayour.com> writes:

> Quoting "Marc G. Fournier" <scrappy@postgresql.org>:
> 
> > For Immediate Release				February 5th, 2002
> > 
> >    Security
> >            A new MD5 encryption option allows more secure storage and
> >            transfer of passwords. A new Unix-domain socket authentication
> >            option is available on Linux and BSD systems.
> 
> First question:
> 
>         Is this backport(-able/-ed) to 7.1.3?

If you're referring to the unix-socket authentication, the Debian
patch for 7.1.X is where it came from--it wasn't in mainline until
7.2.  

> Second question:
> 
>         Is 7.2 ready for production?

The developers obviously think so.  Whether it's true for you, who
knows?  You should probably test it, or wait a few weeks to see if any
show-stopper bugs are turned up by the early adopters.  ;)

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

07 Feb 2002 11:00:18 -0500
Doug McNaught <doug@wireboard.com>
Re: PostgreSQL v7.2 Final Release
>>>>> "Doug" == Doug McNaught <doug@wireboard.com> writes:

    Doug> Turbo Fredriksson <turbo@bayour.com> writes:
    >> Quoting "Marc G. Fournier" <scrappy@postgresql.org>:
    >> 
    >> > For Immediate Release February 5th, 2002
    >> > 
    >> > Security > A new MD5 encryption option allows more secure
    >> storage and > transfer of passwords. A new Unix-domain socket
    >> authentication > option is available on Linux and BSD systems.
    >> 
    >> First question:
    >> 
    >> Is this backport(-able/-ed) to 7.1.3?

    Doug> If you're referring to the unix-socket authentication, the
    Doug> Debian patch for 7.1.X is where it came from--it wasn't in
    Doug> mainline until 7.2.

I was more refering to the on-disk encrypted password. A user (which
have root) found the password in two minutes with grep...

    >> Is 7.2 ready for production?

    Doug> The developers obviously think so.

Good enough. I'll download it and try it out then. Thanx.

Albanian killed subway explosion president Treasury Ft. Meade Iran
World Trade Center BATF Panama ammunition nitrate CIA smuggle
[See http://www.aclu.org/echelonwatch/index.html for more about this]

08 Feb 2002 10:16:51 +0100
Turbo Fredriksson <turbo@bayour.com>
Re: PostgreSQL v7.2 Final Release
The following seems to be a bug in 7.2 (and in 7.1.2) I'm pretty sure
it worked before, certainly it's something I do a lot (but postgresql
isn't the only database I use).

The bug concerns a NOT IN on a list generated by a select. If you
have two tables thus:


  create table t1 (id integer, name varchar(20), t2_id integer);
  insert into t1 (id, name, t2_id) values (1, 'nic', 2);
  insert into t1 (id, name, t2_id) values (2, 'jim', NULL);

  create table t2 (id integer, name varchar(20));
  insert into t1 (id, name, t2_id) values (1, 'ferrier');
  insert into t1 (id, name, t2_id) values (2, 'broadbent');

And now do this query:

  select * from t2 where id not in (select t2_id from t1);

then I get a NULL response (ie: no rows returned).

What I SHOULD get is the row from t2 with id == 2;


Nic Ferrier


01 Apr 2002 15:55:32 +0000
Nic Ferrier <nferrier@tapsellferrier.co.uk>
NOT IN queries
Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

>   create table t1 (id integer, name varchar(20), t2_id integer);
>   insert into t1 (id, name, t2_id) values (1, 'nic', 2);
>   insert into t1 (id, name, t2_id) values (2, 'jim', NULL);
> 
>   create table t2 (id integer, name varchar(20));
>   insert into t1 (id, name, t2_id) values (1, 'ferrier');
>   insert into t1 (id, name, t2_id) values (2, 'broadbent');
> 
> And now do this query:
> 
>   select * from t2 where id not in (select t2_id from t1);
> 
> then I get a NULL response (ie: no rows returned).

Well, you never inserted any rows into t2, so that makes sense.

-Doug
-- 
Doug McNaught       Wireboard Industries      http://www.wireboard.com/

      Custom software development, systems and network consulting.
      Java PostgreSQL Enhydra Python Zope Perl Apache Linux BSD...

01 Apr 2002 11:14:52 -0500
Doug McNaught <doug@wireboard.com>
Re: NOT IN queries
Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>   create table t1 (id integer, name varchar(20), t2_id integer);
>   insert into t1 (id, name, t2_id) values (1, 'nic', 2);
>   insert into t1 (id, name, t2_id) values (2, 'jim', NULL);

>   create table t2 (id integer, name varchar(20));
>   insert into t1 (id, name, t2_id) values (1, 'ferrier');
>   insert into t1 (id, name, t2_id) values (2, 'broadbent');

> And now do this query:

>   select * from t2 where id not in (select t2_id from t1);

> then I get a NULL response (ie: no rows returned).

> What I SHOULD get is the row from t2 with id == 2;

No, you should not; the system's response is correct per spec.

For the t2 row with id=2, the WHERE clause is clearly FALSE
(2 is in select t2_id from t1).  For the t2 row with id=1,
the WHERE clause yields UNKNOWN because of the NULL in t1,
and WHERE treats UNKNOWN as FALSE.  This has been discussed
before on the lists, and it's quite clear that the result is
correct according to SQL's 3-valued boolean logic.

There are a number of ways you could deal with this.  If you
simply want to ignore the NULLs in t1 then you could do either

select * from t2 where id not in (select distinct t2_id from t1);
select * from t2 where (id in (select t2_id from t1)) is not false;

The first of these will probably be faster if there aren't many
distinct t2_id values.

			regards, tom lane

Mon, 01 Apr 2002 11:21:54 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT IN queries 
On 1 Apr 2002, Nic Ferrier wrote:

> The following seems to be a bug in 7.2 (and in 7.1.2) I'm pretty sure
> it worked before, certainly it's something I do a lot (but postgresql
> isn't the only database I use).
>
> The bug concerns a NOT IN on a list generated by a select. If you
> have two tables thus:
>
>
>   create table t1 (id integer, name varchar(20), t2_id integer);
>   insert into t1 (id, name, t2_id) values (1, 'nic', 2);
>   insert into t1 (id, name, t2_id) values (2, 'jim', NULL);
>
>   create table t2 (id integer, name varchar(20));
>   insert into t1 (id, name, t2_id) values (1, 'ferrier');
>   insert into t1 (id, name, t2_id) values (2, 'broadbent');
>
> And now do this query:
>
>   select * from t2 where id not in (select t2_id from t1);
>
> then I get a NULL response (ie: no rows returned).
>
> What I SHOULD get is the row from t2 with id == 2;

Assuming that some of those inserts were supposed to be in t2, you're
misunderstanding how NULLs work. Because there's a NULL in the output
of the subselect, NOT IN is never going to return rows and this is
correct.

The transformations by the spec start out:
RVC NOT IN IPV => NOT (RVC IN IPV) => NOT (RVC =ANY IPV)

The result of RVC =ANY IPV is derived from the application of
= to each row in IPV.  If = is true for at least one row RT
of IPV then RVC =ANY IPV is true.  If IPV is empty or if =
is false for each row RT of IPV then RVC =ANY IPV is false.
If neither of those cases hold, it's unknown.  Since
anything = NULL returns unknown, not false, the last case
is the one that holds. You then NOT the unknown and get
unknown back. Where clauses don't return rows where the
condition is unknown, so you won't get any rows back.



Mon, 1 Apr 2002 08:42:14 -0800 (PST)
Stephan Szabo <sszabo@megazone23.bigpanda.com>
Re: NOT IN queries
Whoops!

Thanks Tom (and everyone else who replied)

And apoloies for the dumb mistake with the inserts (I could try and
pretend it was a deliberate mistake but since I made an even bigger
error I won't do that).


Nic



01 Apr 2002 19:46:55 +0000
Nic Ferrier <nferrier@tapsellferrier.co.uk>
Re: NOT IN queries