On Tue, Apr 28, 2015 at 12:47 PM, Jeff Janes jeff.ja...@gmail.com 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.
On Tue, Apr 7, 2015 at 7:55 PM, Peter Eisentraut pete...@gmx.net 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
2015-03-22 3:55 GMT+01:00 Peter Eisentraut pete...@gmx.net:
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 pete...@gmx.net
mailto:pete...@gmx.net:
On 3/12/15 8:12 AM, Pavel Stehule wrote:
1. fix missing semicolon
2015-03-22 5:45 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
2015-03-22 3:55 GMT+01:00 Peter Eisentraut pete...@gmx.net:
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 pete...@gmx.net
mailto:pete...@gmx.net:
On
2015-03-22 3:55 GMT+01:00 Peter Eisentraut pete...@gmx.net:
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 pete...@gmx.net
mailto:pete...@gmx.net:
On 3/12/15 8:12 AM, Pavel Stehule wrote:
1. fix missing semicolon
On Mon, Mar 16, 2015 at 9:51 PM, Peter Eisentraut pete...@gmx.net 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
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;
use load
2015-03-17 2:51 GMT+01:00 Peter Eisentraut pete...@gmx.net:
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
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.
Hi
I am checking this patch, but it is broken still
Regards
Pavel
2015-02-13 8:14 GMT+01:00 Michael Paquier michael.paqu...@gmail.com:
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 pete...@gmx.net
On Mon, Dec 15, 2014 at 3:10 PM, Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
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 a
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.
On Fri, Jan 10, 2014 at 10:40 PM, Peter Eisentraut pete...@gmx.net 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
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
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
On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut pete...@gmx.net 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
On 12/11/2013 01:40 PM, Robert Haas wrote:
On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut pete...@gmx.net 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
On Wed, Dec 11, 2013 at 9:19 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
On 12/11/2013 01:40 PM, Robert Haas wrote:
On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut pete...@gmx.net wrote:
On Fri, 2013-12-06 at 11:28 +0100, Dimitri Fontaine wrote:
Here is an idea. Add a GUC that basically
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 10, 2013 at 10:35 PM, Peter Eisentraut pete...@gmx.net 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.
Peter Eisentraut pete...@gmx.net 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
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.
Here is
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 something
On 11/15/2013 05:04 PM, Dimitri Fontaine wrote:
Hi,
Peter Eisentraut pete...@gmx.net 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
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 pete...@gmx.net writes:
Let's review
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
On 11/20/2013 10:58 PM, Robert Haas wrote:
On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut pete...@gmx.net 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
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? It's
On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut pete...@gmx.net 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
Hi,
Peter Eisentraut pete...@gmx.net 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
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
On Mon, 2013-07-08 at 23:00 -0700, Hitoshi Harada wrote:
On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut pete...@gmx.net
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
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 bunch of
On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut pete...@gmx.net 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.
On Thu, Jul 4, 2013 at 2:18 AM, Hitoshi Harada umi.tan...@gmail.com 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
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
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
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 on
Josh Berkus j...@agliodbs.com 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
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
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 value in that.
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 that.
On Thu, Jun 13, 2013 at 8:11 PM, Peter Eisentraut pete...@gmx.net 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
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
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 make
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.
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
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 usable,
Peter Eisentraut pete...@gmx.net 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.
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:
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
52 matches
Mail list logo
