Re: [HACKERS] [PATCH] Add transforms feature

On Wed, Apr 29, 2015 at 3:21 PM, Jeff Janes wrote: > On Wed, Apr 29, 2015 at 11:27 AM, Robert Haas wrote: >> On Tue, Apr 28, 2015 at 12:47 PM, Jeff Janes wrote: >> > This commit is causing a compiler warning for me in non-cassert builds: >> > >> > funcapi.c: In function 'get_func_trftypes': >> >

Re: [HACKERS] [PATCH] Add transforms feature

On Wed, Apr 29, 2015 at 11:27 AM, Robert Haas wrote: > On Tue, Apr 28, 2015 at 12:47 PM, Jeff Janes wrote: > > This commit is causing a compiler warning for me in non-cassert builds: > > > > funcapi.c: In function 'get_func_trftypes': > > funcapi.c:890: warning: unused variable 'procStruct' > >

Re: [HACKERS] [PATCH] Add transforms feature

On Tue, Apr 28, 2015 at 12:47 PM, Jeff Janes wrote: > This commit is causing a compiler warning for me in non-cassert builds: > > funcapi.c: In function 'get_func_trftypes': > funcapi.c:890: warning: unused variable 'procStruct' > > Adding PG_USED_FOR_ASSERTS_ONLY seems to fix it. I took a stab a

Re: [HACKERS] [PATCH] Add transforms feature

On Tue, Apr 7, 2015 at 7:55 PM, Peter Eisentraut wrote: > On 3/22/15 5:46 AM, Pavel Stehule wrote: > > Isn't better doesn't support "TRANSFORM ALL" clause? If somebody would > > to use transformations - then he have to explicitly enable it by > > "TRANSFORM FOR TYPE" ? It is safe and without poss

Re: [HACKERS] [PATCH] Add transforms feature

2015-04-08 4:55 GMT+02:00 Peter Eisentraut : > On 3/22/15 5:46 AM, Pavel Stehule wrote: > > Isn't better doesn't support "TRANSFORM ALL" clause? If somebody would > > to use transformations - then he have to explicitly enable it by > > "TRANSFORM FOR TYPE" ? It is safe and without possible user >

Re: [HACKERS] [PATCH] Add transforms feature

2015-03-22 3:55 GMT+01:00 Peter Eisentraut : > Here is an updated patch. > > On 3/17/15 1:11 AM, Pavel Stehule wrote: > > 2015-03-17 2:51 GMT+01:00 Peter Eisentraut > >: > > > > On 3/12/15 8:12 AM, Pavel Stehule wrote: > > > 1. fix missing semicolon pg_proc.h > >

Re: [HACKERS] [PATCH] Add transforms feature

2015-03-22 5:45 GMT+01:00 Pavel Stehule : > > > 2015-03-22 3:55 GMT+01:00 Peter Eisentraut : > >> Here is an updated patch. >> >> On 3/17/15 1:11 AM, Pavel Stehule wrote: >> > 2015-03-17 2:51 GMT+01:00 Peter Eisentraut > > >: >> > >> > On 3/12/15 8:12 AM, Pavel Stehule

Re: [HACKERS] [PATCH] Add transforms feature

2015-03-22 3:55 GMT+01:00 Peter Eisentraut : > Here is an updated patch. > > On 3/17/15 1:11 AM, Pavel Stehule wrote: > > 2015-03-17 2:51 GMT+01:00 Peter Eisentraut > >: > > > > On 3/12/15 8:12 AM, Pavel Stehule wrote: > > > 1. fix missing semicolon pg_proc.h > >

Re: [HACKERS] [PATCH] Add transforms feature

On Mon, Mar 16, 2015 at 9:51 PM, Peter Eisentraut wrote: >> 4. Why guc-use-transforms? Is there some possible negative side effect >> of transformations, so we have to disable it? If somebody don't would to >> use some transformations, then he should not to install some specific >> transformation.

Re: [HACKERS] [PATCH] Add transforms feature

2015-03-17 2:51 GMT+01:00 Peter Eisentraut : > On 3/12/15 8:12 AM, Pavel Stehule wrote: > > 1. fix missing semicolon pg_proc.h > > > > Oid protrftypes[1]; /* types for which to apply > > transforms */ > > Darn, I thought I had fixed that. > > > 2. strange load lib by in sql scr

Re: [HACKERS] [PATCH] Add transforms feature

On 3/12/15 8:12 AM, Pavel Stehule wrote: > 1. fix missing semicolon pg_proc.h > > Oid protrftypes[1]; /* types for which to apply > transforms */ Darn, I thought I had fixed that. > 2. strange load lib by in sql scripts: > > DO '' LANGUAGE plperl; > SELECT NULL::hstore; > >

Re: [HACKERS] [PATCH] Add transforms feature

Hi I am looking to code. Some small issues: 1. fix missing semicolon pg_proc.h Oid protrftypes[1]; /* types for which to apply transforms */ 2. strange load lib by in sql scripts: DO '' LANGUAGE plperl; SELECT NULL::hstore; use load plperl; load hstore; instead 3. missi

Re: [HACKERS] [PATCH] Add transforms feature

Hi I am checking this patch, but it is broken still Regards Pavel 2015-02-13 8:14 GMT+01:00 Michael Paquier : > > > On Mon, Dec 22, 2014 at 12:19 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Mon, Dec 15, 2014 at 3:10 PM, Peter Eisentraut >> wrote: >> > fixed >> This pa

Re: [HACKERS] [PATCH] Add transforms feature

On Mon, Dec 22, 2014 at 12:19 PM, Michael Paquier wrote: > On Mon, Dec 15, 2014 at 3:10 PM, Peter Eisentraut wrote: > > fixed > This patch needs a rebase, it does not apply correctly in a couple of > places on latest HEAD (699300a): > ./src/include/catalog/catversion.h.rej > ./src/include/catalo

Re: [HACKERS] [PATCH] Add transforms feature

On Mon, Dec 15, 2014 at 3:10 PM, Peter Eisentraut wrote: > fixed This patch needs a rebase, it does not apply correctly in a couple of places on latest HEAD (699300a): ./src/include/catalog/catversion.h.rej ./src/include/catalog/pg_proc.h.rej ./src/pl/plpython/plpy_procedure.c.rej Regards, -- Mic

Re: [HACKERS] [PATCH] Add transforms feature

Peter Eisentraut writes: > On 4/4/14 6:21 PM, Andres Freund wrote: > + /* dependency on transform used by return type, if any */ > + if ((trfid = get_transform_oid(returnType, languageObjectId, true))) >> Should be compared to InvalidOid imo, rather than implicitly assuming >> that Inval

Re: [HACKERS] [PATCH] Add transforms feature

On 2014-04-05 00:21:47 +0200, Andres Freund wrote: > On 2014-01-15 21:13:18 -0500, Peter Eisentraut wrote: > > The attached patch will probably fail to apply because of the pg_proc > > changes. So if you want to try it out, look into the header for the Git > > hash it was based off. I'll produce

Re: [HACKERS] [PATCH] Add transforms feature

On 2014-01-15 21:13:18 -0500, Peter Eisentraut wrote: > The attached patch will probably fail to apply because of the pg_proc > changes. So if you want to try it out, look into the header for the Git > hash it was based off. I'll produce a properly merged version when this > approach is validated

Re: [HACKERS] [PATCH] Add transforms feature

On Fri, Jan 10, 2014 at 10:40 PM, Peter Eisentraut wrote: > On Wed, 2013-12-11 at 11:07 -0500, Tom Lane wrote: >> We should have learned by now that those are usually a bad idea. >> In this case, we've got changes in the behavior of function calling, >> which seems like not only a nightmare for de

Re: [HACKERS] [PATCH] Add transforms feature

On Wed, 2013-12-11 at 09:47 -0500, Robert Haas wrote: > Of course, making everyone decorate their new functions with > references to the transforms they want to use isn't wonderful either, > but it might be good at least to have the option. You could allow the > use of all installed transforms by

Re: [HACKERS] [PATCH] Add transforms feature

On Wed, 2013-12-11 at 11:07 -0500, Tom Lane wrote: > We should have learned by now that those are usually a bad idea. > In this case, we've got changes in the behavior of function calling, > which seems like not only a nightmare for debugging but a fertile > source of security issues. I note that

Re: [HACKERS] [PATCH] Add transforms feature

Robert Haas writes: > On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut wrote: >> Here is an updated patch that implements this, makes some of the >> documentation improvements that you suggested, and rebases everything. > I'm still kinda unimpressed by this. Behavior-changing GUC, uggh. We s

Re: [HACKERS] [PATCH] Add transforms feature

On Wed, Dec 11, 2013 at 9:19 AM, Hannu Krosing wrote: > On 12/11/2013 01:40 PM, Robert Haas wrote: >> On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut wrote: >>> On Fri, 2013-12-06 at 11:28 +0100, Dimitri Fontaine wrote: > Here is an idea. Add a GUC that basically says something like >

Re: [HACKERS] [PATCH] Add transforms feature

On 12/11/2013 01:40 PM, Robert Haas wrote: > On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut wrote: >> On Fri, 2013-12-06 at 11:28 +0100, Dimitri Fontaine wrote: Here is an idea. Add a GUC that basically says something like use_transforms = on|off. You can then attach that to indivi

Re: [HACKERS] [PATCH] Add transforms feature

On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut wrote: > On Fri, 2013-12-06 at 11:28 +0100, Dimitri Fontaine wrote: >> > Here is an idea. Add a GUC that basically says something like >> > use_transforms = on|off. You can then attach that to individual >> > functions, which is the right granul

Re: [HACKERS] [PATCH] Add transforms feature

On 12/06/2013 07:25 AM, Peter Eisentraut wrote: > On Tue, 2013-11-26 at 18:10 +0100, Dimitri Fontaine wrote: >> The problem is installing a set of extensions where some of them are >> already using the new transform feature and some of them are not. We >> need a way to cater with that, I think. > H

Re: [HACKERS] [PATCH] Add transforms feature

Peter Eisentraut writes: > Here is an idea. Add a GUC that basically says something like > use_transforms = on|off. You can then attach that to individual > functions, which is the right granularity, because only the function > knows whether its code expects transforms or not. But you can use t

Re: [HACKERS] [PATCH] Add transforms feature

On Tue, 2013-11-26 at 18:10 +0100, Dimitri Fontaine wrote: > The problem is installing a set of extensions where some of them are > already using the new transform feature and some of them are not. We > need a way to cater with that, I think. Here is an idea. Add a GUC that basically says somethi

Re: [HACKERS] [PATCH] Add transforms feature

On 11/15/2013 05:04 PM, Dimitri Fontaine wrote: > Hi, > > Peter Eisentraut writes: >> Rebased patch. No changes except that merge conflicts were resolved, >> and I had to add some Data::Dumper tweaks to the regression tests so >> that the results came out in consistent order on different version

Re: [HACKERS] [PATCH] Add transforms feature

On 11/20/2013 10:58 PM, Robert Haas wrote: > On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut wrote: >> This is a transition problem. Nobody is required to install the >> transforms into their existing databases. They probably shouldn't. > Sure, but that's like saying "nobody's required to use

Re: [HACKERS] [PATCH] Add transforms feature

On 11/12/2013 12:21 PM, Peter Eisentraut wrote: > A transform is an SQL object that supplies to functions for converting > between data types and procedural languages. How hard would it be to extend this to add transforms directly between pairs of procedural languages ? One example would be calli

Re: [HACKERS] [PATCH] Add transforms feature

Hi, Allow me to temporarily skip important questions that you asked so that we can focus on the main problem here. As soon as we decide how to handle any kind of selectivity for the transforms, then I'm back to answering the other things. Peter Eisentraut writes: > Let's review that, as there as

Re: [HACKERS] [PATCH] Add transforms feature

On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut wrote: > This is a transition problem. Nobody is required to install the > transforms into their existing databases. They probably shouldn't. Sure, but that's like saying "nobody's required to use this behavior-changing GUC, so it's OK to have

Re: [HACKERS] [PATCH] Add transforms feature

On 11/15/13, 11:04 AM, Dimitri Fontaine wrote: > - Documentation style seems to be to be different from the "man page" > or "reference docs" style that we use elsewhere, and is instead > deriving the general case from examples. Reads strange. Which specific section do you have in mind?

Re: [HACKERS] [PATCH] Add transforms feature

Hi, Peter Eisentraut writes: > Rebased patch. No changes except that merge conflicts were resolved, > and I had to add some Data::Dumper tweaks to the regression tests so > that the results came out in consistent order on different versions of > Perl. I just spent some time reading that patch,

Re: CREATE TRANSFORM syntax (was Re: [HACKERS] [PATCH] Add transforms feature)

On 08/13/2013 07:16 PM, Peter Eisentraut wrote: > My next best idea is CREATE TRANSFORM FOR hstore SERVER LANGUAGE plperl, > which preserves the overall idea but still distinguishes server from > client languages. > > Comments? My thinking is that TRANSFORMS will almost certainly be managed by in

CREATE TRANSFORM syntax (was Re: [HACKERS] [PATCH] Add transforms feature)

On Mon, 2013-07-08 at 23:00 -0700, Hitoshi Harada wrote: > On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut > wrote: > > On Thu, 2013-07-04 at 02:18 -0700, Hitoshi Harada wrote: > >> as someone suggested in the previous thread, it might be a variant > of > >> CAST. CREATE CAST (hstore AS plpytho

Re: [HACKERS] [PATCH] Add transforms feature

On 07/08/2013 12:00 PM, Josh Berkus wrote: >>> (b) we can expect maybe a dozen to 18 of them in core based on the data >>> >> types there, and I hate to clutter up /contrib, and >> > >> > Well, that's a matter of opinion. I'd be more happy with 250 contribs >> > all on the same level versus a bunc

Re: [HACKERS] [PATCH] Add transforms feature

On Thu, Jul 4, 2013 at 2:18 AM, Hitoshi Harada wrote: > For now, that's it. I'm going to dig more later. > After looking into rest of the change, - TYPTYPE_DOMAIN is not supported. Why did you specifically disallow it? - ParseFuncOrColumn now prohibits to find function returning internal, but

Re: [HACKERS] [PATCH] Add transforms feature

On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut wrote: > On Thu, 2013-07-04 at 02:18 -0700, Hitoshi Harada wrote: >> as someone suggested in the previous thread, it might be a variant of >> CAST. CREATE CAST (hstore AS plpython2u) ? Or CREATE LANGUAGE TRANSFORM >> might sound better. In eithe

Re: [HACKERS] [PATCH] Add transforms feature

Peter, On 07/07/2013 12:06 PM, Peter Eisentraut wrote: > Good point. My original patch allowed func(sql_type) -> internal, but I > took that out because people had security concerns. > > I'd be OK with restricting transform creation to superusers in the first > cut. Have we added the ability of

Re: [HACKERS] [PATCH] Add transforms feature

On Fri, 2013-07-05 at 12:04 -0700, Josh Berkus wrote: > (a) transforms aren't like other contribs, in that they are dependant on > other contribs before you install them. That doesn't appear to be a reason for creating subdirectories. > (b) we can expect maybe a dozen to 18 of them in core based

Re: [HACKERS] [PATCH] Add transforms feature

On Thu, 2013-07-04 at 02:18 -0700, Hitoshi Harada wrote: > as someone suggested in the previous thread, it might be a variant of > CAST. CREATE CAST (hstore AS plpython2u) ? Or CREATE LANGUAGE TRANSFORM > might sound better. In either case, I think we are missing the discussion > on the standard

Re: [HACKERS] [PATCH] Add transforms feature

Josh Berkus writes: > (c) I'd like to do a future feature which supports "install all > transforms" functionality, which would be helped by having them in their > own directory. I think we should install required extensions automatically when they are available. Also, we will need better tooling

Re: [HACKERS] [PATCH] Add transforms feature

On 07/05/2013 09:08 AM, Peter Eisentraut wrote: > On 7/3/13 7:15 PM, Josh Berkus wrote: >> I'm not comfortable with having all of the transform mappings in the >> main contrib/ directory though. Can we add a subdirectory called >> "transforms" containing all of these? > > I don't see any value in

Re: [HACKERS] [PATCH] Add transforms feature

On Friday, July 5, 2013, Peter Eisentraut wrote: > On 7/3/13 7:15 PM, Josh Berkus wrote: > > I'm not comfortable with having all of the transform mappings in the > > main contrib/ directory though. Can we add a subdirectory called > > "transforms" containing all of these? > > I don't see any valu

Re: [HACKERS] [PATCH] Add transforms feature

On 7/3/13 7:15 PM, Josh Berkus wrote: > I'm not comfortable with having all of the transform mappings in the > main contrib/ directory though. Can we add a subdirectory called > "transforms" containing all of these? I don't see any value in that. The data types they apply to are in contrib after

Re: [HACKERS] [PATCH] Add transforms feature

On Thu, Jun 13, 2013 at 8:11 PM, Peter Eisentraut wrote: > A transform is an SQL object that supplies to functions for converting > between data types and procedural languages. For example, a transform > could arrange that hstore is converted to an appropriate hash or > dictionary object in PL/P

Re: [HACKERS] [PATCH] Add transforms feature

Peter, I've been playing with the new patch, and haven't been able to reproduce the load problem created by the original patch. So that seems fixed. I'm not comfortable with having all of the transform mappings in the main contrib/ directory though. Can we add a subdirectory called "transforms"

Re: [HACKERS] [PATCH] Add transforms feature

On 6/17/13 5:31 PM, Alvaro Herrera wrote: > This is a large patch. Do you intend to push the whole thing as a > single commit, or split it? I thought about splitting it up, but I didn't find a reasonable way to do it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] [PATCH] Add transforms feature

On 06/18/2013 04:58 AM, Peter Eisentraut wrote: > On 6/14/13 11:48 PM, Craig Ringer wrote: >> I wonder if that should be extended to install headers for hstore, >> ltree, and while we're at it, intarray as well? > Sure, if someone wants to go through and check which headers are > independently usab

Re: [HACKERS] [PATCH] Add transforms feature

Peter Eisentraut wrote: > A transform is an SQL object that supplies to functions for converting > between data types and procedural languages. For example, a transform > could arrange that hstore is converted to an appropriate hash or > dictionary object in PL/Perl or PL/Python. > > Externally v

Re: [HACKERS] [PATCH] Add transforms feature

On 6/14/13 11:48 PM, Craig Ringer wrote: > I wonder if that should be extended to install headers for hstore, > ltree, and while we're at it, intarray as well? Sure, if someone wants to go through and check which headers are independently usable, and do the necessarily cleanups with necessary.

Re: [HACKERS] [PATCH] Add transforms feature

On 06/14/2013 11:11 AM, Peter Eisentraut wrote: > A transform is an SQL object that supplies to functions for converting > between data types and procedural languages. For example, a transform > could arrange that hstore is converted to an appropriate hash or > dictionary object in PL/Perl or PL/P

Re: [HACKERS] [PATCH] Add transforms feature

On 6/14/13 3:46 AM, Cédric Villemain wrote: > You kept PGXS style makefile... I know, but that's a separate issue that hasn't been decided yet. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-ha

Re: [HACKERS] [PATCH] Add transforms feature

Peter Eisentraut a écrit : >A transform is an SQL object that supplies to functions for converting >between data types and procedural languages. For example, a transform >could arrange that hstore is converted to an appropriate hash or >dictionary object in PL/Perl or PL/Python. Nice ! >Cont