* Tom Lane wrote:
Christian Ullrich 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 plpyth
Christian Ullrich 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 plpython regr
* 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 commit
On Mon, May 4, 2015 at 6:45 AM, Michael Paquier
wrote:
> Hi all,
>
> Coverity complained about a small indentation issue in ruleutils.c:
> + appendStringInfoString(buf, "\n TRANSFORM ");
> + for (i = 0; i < ntypes; i++)
> + {
> + if
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 plpyt
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 s
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 transfo
* 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 it's
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:
http://ww
On 03/13/2013 09:54 AM, Dimitri Fontaine wrote:
> Peter Eisentraut 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
Peter Eisentraut 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 solutions are ei
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
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
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 th
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
Postgr
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_
> 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 (pgsql-hackers@p
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.
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 ju
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
> 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)
T
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
> 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
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
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 inst
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 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.
--
Jo
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).
crea
> 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
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;
> 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, becaus
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
int
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
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 ap
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.
> * Py
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
>
>
On Sat, Jun 16, 2012 at 7:15 PM, Jeff Janes wrote:
> On Thu, Jun 14, 2012 at 3:42 PM, 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.o
On Thu, Jun 14, 2012 at 3:42 PM, 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
When I apply this
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 TRANSFOR
41 matches
Mail list logo
