Re: [HACKERS] Detection of nested function calls

Andres Freund writes: > On 2013-10-28 14:26:20 -0400, Tom Lane wrote: >> No; see my upthread comments. I think what we want to do is to have >> PG_DETOAST_DATUM automatically flatten non-flat datums, and to require >> functions that can cope with non-flat inputs to use a new argument >> fetching

Re: [HACKERS] Detection of nested function calls

On 2013-10-28 14:26:20 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-10-28 13:41:46 -0400, Tom Lane wrote: > >> I don't think that's a safe assumption at all. We need to be able to do > >> flattening anywhere PG_DETOAST_DATUM() can be called. > > > I am not sure we want things to wo

Re: [HACKERS] Detection of nested function calls

Andres Freund writes: > On 2013-10-28 13:41:46 -0400, Tom Lane wrote: >> I don't think that's a safe assumption at all. We need to be able to do >> flattening anywhere PG_DETOAST_DATUM() can be called. > I am not sure we want things to work along those lines. I'd rather make > PG_DETOAST_DATUM p

Re: [HACKERS] Detection of nested function calls

On 2013-10-28 13:41:46 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-10-28 12:42:28 -0400, Tom Lane wrote: > >> Meh. If you don't include a function pointer you will still need the OID > >> of the datatype or the decompression function, so it's not like omitting > >> it is free. > >

Re: [HACKERS] Detection of nested function calls

On Mon, Oct 28, 2013 at 05:48:55PM +0100, Andres Freund wrote: > On 2013-10-28 12:42:28 -0400, Tom Lane wrote: > > Robert Haas writes: > > > On Mon, Oct 28, 2013 at 11:12 AM, Tom Lane wrote: > > >> The idea I'm thinking about at the moment is that toast tokens of this > > >> sort might each conta

Re: [HACKERS] Detection of nested function calls

Andres Freund writes: > On 2013-10-28 12:42:28 -0400, Tom Lane wrote: >> Meh. If you don't include a function pointer you will still need the OID >> of the datatype or the decompression function, so it's not like omitting >> it is free. > That's what I thought at first too - but I am not sure it

Re: [HACKERS] Detection of nested function calls

On 2013-10-28 12:42:28 -0400, Tom Lane wrote: > Robert Haas writes: > > On Mon, Oct 28, 2013 at 11:12 AM, Tom Lane wrote: > >> The idea I'm thinking about at the moment is that toast tokens of this > >> sort might each contain a function pointer to the required flattening > >> function. > > > Th

Re: [HACKERS] Detection of nested function calls

Robert Haas writes: > On Mon, Oct 28, 2013 at 11:12 AM, Tom Lane wrote: >> The idea I'm thinking about at the moment is that toast tokens of this >> sort might each contain a function pointer to the required flattening >> function. > This might be OK, but it bloats the in-memory representation.

Re: [HACKERS] Detection of nested function calls

On Mon, Oct 28, 2013 at 11:12 AM, Tom Lane wrote: > The idea I'm thinking about at the moment is that toast tokens of this > sort might each contain a function pointer to the required flattening > function. This avoids an expensive catalog lookup when flattening is > needed. We'd never accept su

Re: [HACKERS] Detection of nested function calls

Hugo Mercier writes: > Le 25/10/2013 18:44, Tom Lane a écrit : >> The point I'm trying to make is that in the first case, foo would be >> receiving a first argument that was flat and a second that was not flat; >> while in the second case, it would be receiving a first argument that was >> not fla

Re: [HACKERS] Detection of nested function calls

2013/10/28 Andres Freund > On 2013-10-28 10:12:41 +0100, Pavel Stehule wrote: > > > I think we'd need another argument to CREATE FUNCTION like SERIALIZE > > > pointing to a function that that has to return data that can be stored > > > on disk. Deserialization would be up to individual functions.

Re: [HACKERS] Detection of nested function calls

On 2013-10-28 10:29:59 +0100, Hugo Mercier wrote: > Le 28/10/2013 09:39, Andres Freund a écrit : > > On 2013-10-28 09:13:06 +0100, Hugo Mercier wrote: > >> Le 25/10/2013 18:44, Tom Lane a écrit : > >>> Hugo Mercier writes: > Le 25/10/2013 17:20, Tom Lane a écrit : > > How do you tell the

Re: [HACKERS] Detection of nested function calls

Le 28/10/2013 09:39, Andres Freund a écrit : > On 2013-10-28 09:13:06 +0100, Hugo Mercier wrote: >> Le 25/10/2013 18:44, Tom Lane a écrit : >>> Hugo Mercier writes: Le 25/10/2013 17:20, Tom Lane a écrit : > How do you tell the difference between >>> The point I'm trying to make is that i

Re: [HACKERS] Detection of nested function calls

On 2013-10-28 10:12:41 +0100, Pavel Stehule wrote: > > I think we'd need another argument to CREATE FUNCTION like SERIALIZE > > pointing to a function that that has to return data that can be stored > > on disk. Deserialization would be up to individual functions. > > > > Depending on the specifica

Re: [HACKERS] Detection of nested function calls

2013/10/28 Andres Freund > On 2013-10-28 09:13:06 +0100, Hugo Mercier wrote: > > Le 25/10/2013 18:44, Tom Lane a écrit : > > > Hugo Mercier writes: > > >> Le 25/10/2013 17:20, Tom Lane a écrit : > > >>> How do you tell the difference between > > >>> > > >>> foo(col1, bar(col2)) > > >>> foo(bar(c

Re: [HACKERS] Detection of nested function calls

On 2013-10-28 09:13:06 +0100, Hugo Mercier wrote: > Le 25/10/2013 18:44, Tom Lane a écrit : > > Hugo Mercier writes: > >> Le 25/10/2013 17:20, Tom Lane a écrit : > >>> How do you tell the difference between > >>> > >>> foo(col1, bar(col2)) > >>> foo(bar(col1), col2) > > > >> Still not sure to und

Re: [HACKERS] Detection of nested function calls

Le 25/10/2013 18:44, Tom Lane a écrit : > Hugo Mercier writes: >> Le 25/10/2013 17:20, Tom Lane a écrit : >>> How do you tell the difference between >>> >>> foo(col1, bar(col2)) >>> foo(bar(col1), col2) > >> Still not sure to understand ... >> I assume foo() takes two argument of type A. >> bar()

Re: [HACKERS] Detection of nested function calls

On Fri, Oct 25, 2013 at 10:18 AM, Tom Lane wrote: > Hugo Mercier writes: >> PostGIS functions that manipulate geometries have to unserialize their >> input geometries from the 'flat' varlena representation to their own, >> and serialize the processed geometries back when returning. >> But in such

Re: [HACKERS] Detection of nested function calls

Hugo Mercier writes: > Le 25/10/2013 17:20, Tom Lane a écrit : >> How do you tell the difference between >> >> foo(col1, bar(col2)) >> foo(bar(col1), col2) > Still not sure to understand ... > I assume foo() takes two argument of type A. > bar() can take one argument of A or another type B. I w

Re: [HACKERS] Detection of nested function calls

Le 25/10/2013 17:20, Tom Lane a écrit : > Hugo Mercier writes: >> Le 25/10/2013 16:18, Tom Lane a écrit : > How do you tell the difference between > >foo(col1, bar(col2)) >foo(bar(col1), col2) > Still not sure to understand ... I assume foo() takes two argument of type A. bar()

Re: [HACKERS] Detection of nested function calls

Hugo Mercier writes: > Le 25/10/2013 16:18, Tom Lane a écrit : >> However, this seems like a completely wrong way to go at it. In the first >> place, it wouldn't help for situations like a complex value stored in a >> plpgsql variable. In the second, I don't think that what you are >> describing

Re: [HACKERS] Detection of nested function calls

On 2013-10-25 11:01:28 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-10-25 10:18:27 -0400, Tom Lane wrote: > >> I think the right way to attack it is to create some way for a Datum > >> value to indicate, at runtime, whether it's a flat value or an in-memory > >> representation. > >

Re: [HACKERS] Detection of nested function calls

Le 25/10/2013 16:18, Tom Lane a écrit : > Hugo Mercier writes: >> PostGIS functions that manipulate geometries have to unserialize their >> input geometries from the 'flat' varlena representation to their own, >> and serialize the processed geometries back when returning. >> But in such nested cal

Re: [HACKERS] Detection of nested function calls

Andres Freund writes: > On 2013-10-25 10:18:27 -0400, Tom Lane wrote: >> I think the right way to attack it is to create some way for a Datum >> value to indicate, at runtime, whether it's a flat value or an in-memory >> representation. > That sounds reasonable, and we have most of the infrastruc

Re: [HACKERS] Detection of nested function calls

On 2013-10-25 10:18:27 -0400, Tom Lane wrote: > I think the right way to attack it is to create some way for a Datum > value to indicate, at runtime, whether it's a flat value or an in-memory > representation. Any given function returning the type could choose to > return either representation. T

Re: [HACKERS] Detection of nested function calls

Hugo Mercier writes: > PostGIS functions that manipulate geometries have to unserialize their > input geometries from the 'flat' varlena representation to their own, > and serialize the processed geometries back when returning. > But in such nested call queries, this serialization-unserialization

Re: [HACKERS] Detection of nested function calls

2013/10/25 Hugo Mercier > Le 25/10/2013 14:29, Pavel Stehule a écrit : > > Hello > > > > > > 2013/10/25 Hugo Mercier > >. > > > > I am quite new to postgresql hacking, so I'm sure there is room for > > improvements. But, what about this first proposal ?

Re: [HACKERS] Detection of nested function calls

Le 25/10/2013 14:29, Pavel Stehule a écrit : > Hello > > > 2013/10/25 Hugo Mercier >. > > I am quite new to postgresql hacking, so I'm sure there is room for > improvements. But, what about this first proposal ? > > > I am not sure, if this solution i

Re: [HACKERS] Detection of nested function calls

Hello 2013/10/25 Hugo Mercier > Hi all, > > The Oslandia team is involved in PostGIS project for years, with a > current focus on PostGIS 3D support. > With PostGIS queries, nested functions calls that manipulate geometries > are quite common, e.g.: SELECT ST_Union(ST_Intersection(a.geom, > ST_

[HACKERS] Detection of nested function calls

Hi all, The Oslandia team is involved in PostGIS project for years, with a current focus on PostGIS 3D support. With PostGIS queries, nested functions calls that manipulate geometries are quite common, e.g.: SELECT ST_Union(ST_Intersection(a.geom, ST_Buffer(b.geom, 50))) PostGIS functions that ma