Christian Ullrich ch...@chrullrich.net writes:
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant
* Tom Lane wrote:
Christian Ullrich ch...@chrullrich.net writes:
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since
On Mon, May 4, 2015 at 6:45 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
Hi all,
Coverity complained about a small indentation issue in ruleutils.c:
+ appendStringInfoString(buf, \n TRANSFORM );
+ for (i = 0; i ntypes; i++)
+ {
+
Hi all,
Coverity complained about a small indentation issue in ruleutils.c:
+ appendStringInfoString(buf, \n TRANSFORM );
+ for (i = 0; i ntypes; i++)
+ {
+ if (i != 0)
+ appendStringInfoString(buf, ,
On 05/01/2015 08:57 AM, Andrew Dunstan wrote:
On 04/30/2015 09:09 PM, Christian Ullrich wrote:
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the
On 04/30/2015 09:09 PM, Christian Ullrich wrote:
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit
* Andrew Dunstan:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit seems to be the transforms feature.
Here's what
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant commit seems to be the transforms
On 6/12/13 1:20 AM, Josh Berkus wrote:
Peter, All:
Does anyone feel like fixing the LOAD issue with transforms? I haven't
seen any activity on the patch.
I plan to send in an updated patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter, All:
Does anyone feel like fixing the LOAD issue with transforms? I haven't
seen any activity on the patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 03/13/2013 09:54 AM, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
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
Peter Eisentraut pete...@gmx.net writes:
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
On 2013-03-11 20:28:05 -0400, Peter Eisentraut wrote:
On Mon, 2013-03-11 at 18:11 +0100, Andres Freund wrote:
If we don't find a better solution, yes. Why don't we lookup type
input/ouput function for parameters and return type during CREATE
FUNCTION? That should solve the issue in a neater
Your error looks like youre erroring out in plperl not in hstore?
Look again.
Peter, is there any way for you to tackle this issue? I have no idea
how to fix it, myself ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
On 2013-03-11 09:42:18 -0700, Josh Berkus wrote:
Your error looks like youre erroring out in plperl not in hstore?
Look again.
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
On 03/11/2013 09:50 AM, Andres Freund wrote:
DO LANGUAGE plperlu ;
SELECT NULL::hstore;
Aha, so that's what you meant!
Yeah, it works if I reference both extensions before the CREATE EXTENSION.
In that case, seems like that could be added to the extension SQL, no?
--
Josh Berkus
On 2013-03-11 09:55:34 -0700, Josh Berkus wrote:
On 03/11/2013 09:50 AM, Andres Freund wrote:
DO LANGUAGE plperlu ;
SELECT NULL::hstore;
Aha, so that's what you meant!
Yeah, it works if I reference both extensions before the CREATE EXTENSION.
In that case, seems like that could
On Mon, 2013-03-11 at 18:11 +0100, Andres Freund wrote:
If we don't find a better solution, yes. Why don't we lookup type
input/ouput function for parameters and return type during CREATE
FUNCTION? That should solve the issue in a neater way?
A function in general has no particular use for a
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
Peter,
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.
Just invoking code doesn't seem to be enough. I tried just
On 2013-03-06 09:53:29 -0800, Josh Berkus wrote:
Peter,
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.
Just
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).
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.
--
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,
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
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
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
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:
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
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
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
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
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 (creating the extensions) works fine for me on a Ubuntu 10.x system
H. 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
Here is an updated patch for the transforms feature. The previous
discussion was here:
http://www.postgresql.org/message-id/1339713732.11971.79.ca...@vanquo.pezone.net
Old news: At the surface, this contains:
- New catalog pg_transform
- CREATE/DROP TRANSFORM
As proofs of concept and useful
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.
*
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
On Thu, Jun 14, 2012 at 3:42 PM, Peter Eisentraut pete...@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
On Sat, Jun 16, 2012 at 7:15 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Jun 14, 2012 at 3:42 PM, Peter Eisentraut pete...@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:
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
41 matches
Mail list logo
