transforms

On Thu, Jun 14, 2012 at 3:42 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

Here is my first patch for the transforms feature.  This is a mechanism
to adapt data types to procedural languages.  The previous proposal was
here: http://archives.postgresql.org/pgsql-hackers/2012-05/msg00728.php

When I apply this and go to contrib and do make check, I get:

In file included from hstore_plperl.c:4:0:
../../src/pl/plperl/plperl.h:49:20: fatal error: EXTERN.h: No such
file or directory

Cheers,

Jeff

On Sat, Jun 16, 2012 at 7:15 PM, Jeff Janes <jeff.janes@gmail.com> wrote:

On Thu, Jun 14, 2012 at 3:42 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

Here is my first patch for the transforms feature.  This is a mechanism
to adapt data types to procedural languages.  The previous proposal was
here: http://archives.postgresql.org/pgsql-hackers/2012-05/msg00728.php

When I apply this and go to contrib and do make check, I get:

In file included from hstore_plperl.c:4:0:
../../src/pl/plperl/plperl.h:49:20: fatal error: EXTERN.h: No such
file or directory

Ah, that went away when I remembered to ./configure --with-perl

Although the error message seem less than optimal. Aren't test
usually "skipped" when they are missing prerequisites in the config?

Cheers,

Jeff

Hi Peter,

On Friday, June 15, 2012 12:42:12 AM Peter Eisentraut wrote:

Here is my first patch for the transforms feature. This is a mechanism
to adapt data types to procedural languages. The previous proposal was
here: http://archives.postgresql.org/pgsql-hackers/2012-05/msg00728.php

At the surface, this contains:

- New catalog pg_transform

- CREATE/DROP TRANSFORM

Cursory code review:
* pstrndup already exists as pnstrdup (hstore_plperl.c)
* PyString_FromStringAndSize return value not decreffed? PyDict_SetItem
doesn't steal references
* In plpython_to_hstore I would move the 'pairs' and some related variables in
the PG_TRY block, so the reader doesn't need to check whether it should be
volatile
* In the same function items needs to be volatile to fit into longjmp
semantics
* I don't think recording dependencies on transforms used when creating
functions is a good idea as the transform might get created after the
functions already exists. That seems to be a pretty confusing behaviour.
* I am a bit wary that some place can be used to call functions accepting
INTERNAL indirectly, couldn't think of any immediately though. Will look into
this a bit, but I am not experienced in the area, so ...
* I forsee the need for multiple transforms for the same type/language pair to
coexist. The user would need to manually "choose"/"call" the transform in that
case. This currently isn't easily possible...

*) No psql backslash commands yet. Could be added.

Doesn't really seem necessary to me. Not many people will need to look at this
and the list of commands already is rather long.

*) Permissions: Transforms don't have owners, a bit like casts.
Currently, you are allowed to drop a transform if you own both the type
and the language. That might be too strict, maybe own the type and have
privileges on the language would be enough.

Seems sensible enough to me.

*) If we want to offer the ability to write transforms to end users,
then we need to install all the header files for the languages and the
types. This actually worked quite well; including hstore.h and plperl.h
for example, gave you what you needed. In other cases, some headers
might need cleaning up. Also, some magic from the plperl and plpython
build systems might need to be exposed, for example to find the header
files. See existing modules for how this currently looks.

Doesn't look to bad to me. I dont't know how this could be made easier.

*) There is currently some syntax schizophrenia. The grammar accepts

CREATE TRANSFORM FOR hstore LANGUAGE plperl (
FROM SQL WITH hstore_to_plperl,
TO SQL WITH plperl_to_hstore
);

but pg_dump produces

CREATE TRANSFORM FOR hstore LANGUAGE plperl (
FROM SQL WITH hstore_to_plperl(hstore),
TO SQL WITH plperl_to_hstore(internal)
);

The SQL standard allows both. (In the same way that it allows 'DROP
FUNCTION foo' without arguments, if it is not ambigious.) Precedent is
that CREATE CAST requires arguments, but CREATE LANGUAGE does not.

I don't find that problematic personally.

Greetings,

Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

I haven't had the time to finish all the issues with this, but I want to
keep the discussion going in the meantime and provide an updated patch.

On mån, 2012-06-18 at 17:33 +0200, Andres Freund wrote:

Cursory code review:
* pstrndup already exists as pnstrdup (hstore_plperl.c)

Fixed.

* PyString_FromStringAndSize return value not decreffed? PyDict_SetItem
doesn't steal references

Fixed.

* In plpython_to_hstore I would move the 'pairs' and some related variables in
the PG_TRY block, so the reader doesn't need to check whether it should be
volatile
* In the same function items needs to be volatile to fit into longjmp
semantics

I'll recheck that later.

* I don't think recording dependencies on transforms used when creating
functions is a good idea as the transform might get created after the
functions already exists. That seems to be a pretty confusing behaviour.

We need the dependencies, because otherwise dropping a transform would
break or silently alter the behavior of functions that depend on it.
That sounds like my worst nightmare, thinking of some applications that
would be affected by that. But your point is a good one. I think this
could be addressed by prohibiting the creation of a transform that
affects functions that already exist.

Because the legacy behavior of PL implementations of defaulting to a
string representation conversion, we would technically need a dependency
on the absence of a transform object to make this airtight. In the far
future, I could imagine removing this default behavior, meaning you
couldn't create the function if no suitable transforms exist for all
argument and return types.

* I forsee the need for multiple transforms for the same type/language pair to
coexist. The user would need to manually "choose"/"call" the transform in that
case. This currently isn't easily possible...

I thought about this briefly at the beginning, but see under "worst
nightmare" above. Also, having a configuration setting for this or
something would prevent any PL functions from being immutable. We don't
allow multiple casts or multiple in/out functions either, which are
related concepts. If you want different behavior, you should define a
different type or different language.

*) No psql backslash commands yet. Could be added.

Doesn't really seem necessary to me. Not many people will need to look at this
and the list of commands already is rather long.

I'm going to leave this out for now.

*) Permissions: Transforms don't have owners, a bit like casts.
Currently, you are allowed to drop a transform if you own both the type
and the language. That might be too strict, maybe own the type and have
privileges on the language would be enough.

Seems sensible enough to me.

I have made this change.

*) There is currently some syntax schizophrenia. The grammar accepts

CREATE TRANSFORM FOR hstore LANGUAGE plperl (
FROM SQL WITH hstore_to_plperl,
TO SQL WITH plperl_to_hstore
);

but pg_dump produces

CREATE TRANSFORM FOR hstore LANGUAGE plperl (
FROM SQL WITH hstore_to_plperl(hstore),
TO SQL WITH plperl_to_hstore(internal)
);

The SQL standard allows both. (In the same way that it allows 'DROP
FUNCTION foo' without arguments, if it is not ambigious.) Precedent is
that CREATE CAST requires arguments, but CREATE LANGUAGE does not.

I don't find that problematic personally.

I have fixed the syntax to include argument types, so the dump output
and the input grammar is consistent.

Other changes:

- Fixed ecpg grammar to work again with this.

- Changed extension naming to be more consistent.

- Build additional contrib modules conditionally depending on whether
--with-perl or --with-python were configured. (complaint from Jeff
Janes)

- Fixed Python 3.

Things I still want to do:

- Refactor the regression test framework for Python 3 so that contrib
modules or external extensions don't have to repeat the magic in
src/pl/plpython/Makefile. (Python 3 with hstore_plpython and
ltree_plpython works, but the tests don't run.)

- Refactor pyobject_to_string(), which is currently kind of copied and
pasted from plpython, but should instead be exported by plpython in some
suitable way.

- Refactor shared library building so that I can have, say, hstore,
hstore_plperl, and hstore_plpython in one directory, rather than in
three. The reason being, if someone has a new type in a repository on
github or something, I don't want them to have to make three separate
projects or some crazy subdirectory structure in order to add some PL
support for their type. This will require some deep Makefile.shlib
hacking, but I think it's worth trying to make this simple(r).

So, it's quite likely that this patch won't get finished in this commit
fest.

Here is an updated patch for the transforms feature. The previous
discussion was here:
/messages/by-id/1339713732.11971.79.camel@vanquo.pezone.net

Old news: At the surface, this contains:

- New catalog pg_transform

- CREATE/DROP TRANSFORM

As proofs of concept and useful applications, I have included transforms for

- PL/Perl - hstore
- PL/Python - hstore
- PL/Python - ltree

New news: I have tried to address all issues raised during previous
reviews.

The regression tests for hstore_plpython and ltree_plpython don't pass
with Python 3. This needs to be fixed, obviously, but it's an issue
unrelated to the core functionality.

As a demo that this can be used externally as well, I have written a
proof-of-concept transform between plpython and the mpz type in the pgmp
extension (multi-precision arithmetic extension):
https://github.com/petere/pgmp/tree/transforms/plpython

Note: There was a lot of churn lately in src/backend/commands/, and I
had to fix merge conflicts several times, so you need source as of about
right now to apply this patch cleanly.

Side issue/peculiarity: I had to change some shared library linking
flags for OS X. Ordinarily, when linking a dynamically loadable module
on OS X, if there are unresolved symbols, it's an error. But for
example, when we link hstore_plpython, we expect some symbols to be
resolved in hstore.so or plpythonu.so, so we need to ignore unresolved
symbols. This change basically just makes OS X behave like other
platforms in this regard. There might be other portability issues on
other platforms.

Peter,

I tried this patch out. I didn't get as far as testing the
functionality because of errors.

configure/make/make install/make check worked, without asserts. I
believe DF found some errors when he enabled assertions.

When I tried to install the actual transform extensions, though, it blew
up with symbol errors:

transforms=# create extension hstore
transforms-# ;
CREATE EXTENSION

transforms=# create extension ltree
transforms-# ;
CREATE EXTENSION

transforms=# create extension plperl
transforms-# ;
CREATE EXTENSION

transforms=# create extension plpythonu
transforms-# ;
CREATE EXTENSION

transforms=# create extension ltree_plpythonu;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/ltree_plpython2.so":
/home/josh/pg93/lib/postgresql/ltree_plpython2.so: undefined symbol:
PyList_New
STATEMENT: create extension ltree_plpythonu;

transforms=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;

This surprised me, because "make check" for the extensions passed fine.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter, all:

So in addition to the bugs I encountered in getting this patch to work,
we have a design issue to work out: how to load all of the transform
functions. Each transform depends on an optional datatype (like hstore)
and an optional external language (like plperl), which can be loaded
into the database in any order.

Currently Peter is punting (as is proper in a new patch) by having a
separate extension for each combination (hstore/plperl, hstore/plpython,
ltree/plpython, etc.). This is obviously not a maintainable approach in
the long run.

In an ideal world, transformations would load automatically as soon as
all of their prerequisites load. For example, if you load hstore and
plpythonU, then hstore_plpython should automatically load whenever the
second extension is loaded.

However, we currently have no mechanism for this, especially since we
don't know what order the user will load the two extensions in.
Realistically, this would require enhancing the extension mechanism to
track transformations.

Discuss?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

transforms=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;

This surprised me, because "make check" for the extensions passed fine.

Oh, this is on Ubuntu 12.10, not OSX. So possibly the fixes you made
to fix linking on OSX broke other platforms.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 13-03-03 06:15 PM, Josh Berkus wrote:

transforms=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;

This surprised me, because "make check" for the extensions passed fine.

Oh, this is on Ubuntu 12.10, not OSX. So possibly the fixes you made
to fix linking on OSX broke other platforms.

This (creating the extensions) works fine for me on a Ubuntu 10.x system

template1=# create database test;
CREATE DATABASE
template1=# \c test
You are now connected to database "test" as user "ssinger".
test=# create extension hstore;
CREATE EXTENSION
test=# create extension hstore_plpythonu;
ERROR: required extension "plpythonu" is not installed
STATEMENT: create extension hstore_plpythonu;
ERROR: required extension "plpythonu" is not installed
test=# create extension plpythonu;
CREATE EXTENSION
test=# create extension hstore_plpythonu;
CREATE EXTENSION
test=#
test=# create extension plperl;
CREATE EXTENSION
test=# create extension hstore_plperl;
CREATE EXTENSION
test=# create extension plperlu;
CREATE EXTENSION
test=# create extension hstore_plperlu;
CREATE EXTENSION
test=#

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

This (creating the extensions) works fine for me on a Ubuntu 10.x system

Hmmmm. So I wiped everything out and retried this with clean
directories, and it worked fine. Now I'm not sure how I got the error
in the first place.

Anyway, the feature seems to work as expected:

create function look_up_hstore (
some_hs hstore, which_key text )
returns text
language plpythonu as $f$
return some_hs[which_key]
$f$;

postgres=# create table storit ( it hstore );
CREATE TABLE

postgres=# insert into storit values ( 'f => josh,l=>berkus'
),('f=>jan,l=>wieck'),('f=>tom,l=>lane');
INSERT 0 3
postgres=# select look_up_hstore(it,'f') from storit;
look_up_hstore
----------------
josh
jan
tom
(3 rows)

I'll have to think of other ways to test it out, but right now it seems
to pass muster. I was a little unclear on what Python data structure an
ltree should produce.

Now if only we can work out the combinatorics issue ...

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 13-03-03 08:13 PM, Josh Berkus wrote:

This (creating the extensions) works fine for me on a Ubuntu 10.x system

Now if only we can work out the combinatorics issue ...

The plpython2u extensions worked fine but I haven't been able to get
this to work with plpython3u (python 3.1).

create extension hstore_plpython3u;
ERROR: could not load library
"/usr/local/pgsql93git/lib/hstore_plpython3.so":
/usr/local/pgsql93git/lib/hstore_plpython3.so: undefined symbol:
_Py_NoneStruct

Peter mentioned in the submission that the unit tests don't pass with
python3, it doesn't work for meoutside the tests either.

Steve

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter mentioned in the submission that the unit tests don't pass with
python3, it doesn't work for meoutside the tests either.

Also, note that the feature is the concept of Transforms, not the
individual transforms which Peter provides. The idea is to enable a new
kind of extension.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/3/13 6:14 PM, Josh Berkus wrote:

Currently Peter is punting (as is proper in a new patch) by having a
separate extension for each combination (hstore/plperl, hstore/plpython,
ltree/plpython, etc.). This is obviously not a maintainable approach in
the long run.

There is also a {Perl, Python, Ruby, etc.} binding for {libpq, libmysql,
libpng, libyaml, libssl, libgmp, etc.}, each as a separately
downloadable and buildable package. I don't think anyone has ever
seriously considered a system by which if, say, you have Python and
libyaml installed, pyyaml magically appears. Might be nice, but maybe
not. The solution, in practice, is that you download pyyaml, and it
pulls in any required dependencies. This would work the same way.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter,

There is also a {Perl, Python, Ruby, etc.} binding for {libpq, libmysql,
libpng, libyaml, libssl, libgmp, etc.}, each as a separately
downloadable and buildable package. I don't think anyone has ever
seriously considered a system by which if, say, you have Python and
libyaml installed, pyyaml magically appears. Might be nice, but maybe
not. The solution, in practice, is that you download pyyaml, and it
pulls in any required dependencies. This would work the same way.

That would be good too, although we don't currently have that
capability; if I try to install hstore_plpython without plpython
installed, it just errors out. Aside from that, what can we reasonably
do for 9.3 to get this feature in?

Maybe we add a transforms/ subdirectory of contrib, so that it can be as
crowded as we want? Or put the transforms on PGXN for now?

I want to see this feature go in so that the community starts writing
transforms this year instead of next year.

BTW, dependancies seem to be working OK for DROP:

postgres=# drop extension plpythonu;
ERROR: cannot drop extension plpythonu because other objects depend on it
DETAIL: extension hstore_plpythonu depends on extension plpythonu
function look_up_hstore(hstore,text) depends on transform for hstore
language plpythonu
extension ltree_plpythonu depends on extension plpythonu
HINT: Use DROP ... CASCADE to drop the dependent objects too.
STATEMENT: drop extension plpythonu;
ERROR: cannot drop extension plpythonu because other objects depend on it
DETAIL: extension hstore_plpythonu depends on extension plpythonu
function look_up_hstore(hstore,text) depends on transform for hstore
language plpythonu
extension ltree_plpythonu depends on extension plpythonu
HINT: Use DROP ... CASCADE to drop the dependent objects too.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter,

I'm still getting intermittent linking failures:

postgres=# drop extension plperl cascade;
NOTICE: drop cascades to extension hstore_plperl
DROP EXTENSION

postgres=# create extension plperl;
CREATE EXTENSION
postgres=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
postgres=#

There appears to be something wonky which breaks when I've been running
9.2, shut it down, and fire up 9.3.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

postgres=# create extension plperl;
CREATE EXTENSION
postgres=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
postgres=#

There appears to be something wonky which breaks when I've been running
9.2, shut it down, and fire up 9.3.

More on this: the problem appears to be that the symbols for hstore are
loaded only if I've just just created the extension in that database:

postgres=# create database plperlh
postgres-# ;
CREATE DATABASE
postgres=# \c plperlh;
You are now connected to database "plperlh" as user "josh".
plperlh=# create extension plperl;
CREATE EXTENSION
plperlh=# create extension hstore;
CREATE EXTENSION
plperlh=# create extension hstore_plperl;
CREATE EXTENSION
plperlh=#

plperlh=# \c postgres
You are now connected to database "postgres" as user "josh".
postgres=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
PL_thr_key
STATEMENT: create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
PL_thr_key

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 03/05/2013 02:52 PM, Josh Berkus wrote:

plperlh=# \c postgres
You are now connected to database "postgres" as user "josh".
postgres=# create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
PL_thr_key
STATEMENT: create extension hstore_plperl;
ERROR: could not load library
"/home/josh/pg93/lib/postgresql/hstore_plperl.so":
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
PL_thr_key

What happens if you set your LD_LIBRARY_PATH to reflect each
installation before you start the database?

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

What happens if you set your LD_LIBRARY_PATH to reflect each
installation before you start the database?

No change, at least not setting it to $PGHOME/lib.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/5/13 5:52 PM, Josh Berkus wrote:

More on this: the problem appears to be that the symbols for hstore are
loaded only if I've just just created the extension in that database:

I see. This is a problem with any kind of dynamically loadable module
that uses another module. The other module is only loaded either at
creation time or when a function from it is first used (or if a preload
mechanism is used).

At run time, this will sort itself out, because all the required modules
will be loaded. The problem is when you create the "glue" extension and
haven't invoked any code from any of the dependent extension in the
session. Abstractly, the possible solutions are either not to check the
functions when the extension is created (possibly settable by a flag) or
to somehow force a load of all dependent extensions when the new
extension is created. (I say extension here even though dynamically
loadable modules are attached to functions, which makes this even more
confusing.)

In "normal" programming languages, this is normally addressed by placing
explicit load/require/import statements before you do anything else.
What we are doing here is more like an autoload functionality that some
environments have. Those have the same problem.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers