Обсуждение: Aggregates with internal state type?

Hi,

The PostgreSQL allows functions to define "internal" as parameter and
return types for functions, when those are not visible from SQL.

This lead me to the question whether it is possible to use "internal" as
state type for an Aggregate whose functions are implemented in C.

Thanks,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

Markus Schaber <schabi@logix-tt.com> writes:
> This lead me to the question whether it is possible to use "internal" as
> state type for an Aggregate whose functions are implemented in C.

No, because the system has no idea what the representation of an
"internal" state value might be, and in particular how to copy it.
The same goes for other pseudotypes.
        regards, tom lane

Hi, Tom,

Tom Lane wrote:
> Markus Schaber <schabi@logix-tt.com> writes:
>> This lead me to the question whether it is possible to use "internal" as
>> state type for an Aggregate whose functions are implemented in C.
> 
> No, because the system has no idea what the representation of an
> "internal" state value might be, and in particular how to copy it.
> The same goes for other pseudotypes.

Ah, I see. So there's no possibility to pass some void* kind of
intermediate data, I have to craft at least a dummy PostgreSQL datatype
for it.

This also solves the question how such things would be cleaned up in
case of an intermediate error.

Thanks,

Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

Markus Schaber <schabi@logix-tt.com> writes:
> Ah, I see. So there's no possibility to pass some void* kind of
> intermediate data, I have to craft at least a dummy PostgreSQL datatype
> for it.

Right.  My first thought would be to use bytea as the declared type ---
doesn't put much burden on you except to have a length word at the front.
        regards, tom lane

Hi, Tom,

Tom Lane wrote:

>> Ah, I see. So there's no possibility to pass some void* kind of
>> intermediate data, I have to craft at least a dummy PostgreSQL datatype
>> for it.
> 
> Right.  My first thought would be to use bytea as the declared type ---
> doesn't put much burden on you except to have a length word at the front.

Yes, that will work for C, and I'll have a look into it. Good idea.

I had the secret hope that I'd come up with a scheme that also works
using pljava, avoiding the serialization and reserialization of java
objects. But I'm afraid that this gets more difficult.

Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

Hi, Tom,

Markus Schaber wrote:

>>> This lead me to the question whether it is possible to use "internal" as
>>> state type for an Aggregate whose functions are implemented in C.
>> No, because the system has no idea what the representation of an
>> "internal" state value might be, and in particular how to copy it.
>> The same goes for other pseudotypes.
> Ah, I see. So there's no possibility to pass some void* kind of
> intermediate data, I have to craft at least a dummy PostgreSQL datatype
> for it.
> This also solves the question how such things would be cleaned up in
> case of an intermediate error.

As we are at it:

How would you estimate the chances for a Patch to get included that lets
C functions pass some void* data pointer around in an aggregate, when
the aggregate provides a custom "clean-up" function that gets called
whenever the scan gets aborted prematurely?

I assume that this could help speeding up e. G. Array Aggregates, or
PostGIS geomUnion() or string concatenations etc.

Thanks,
Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org