Re: Non-storable data type

Hello,

writing an extension library, I have a type only used to perform
efficient in-place aggregation, but absolutely not to be used as a
data type into a table (it contains pointers, so it would be a
guaranteed crash).

Is there a way to mark the type as non-storable?

Thanks,

-- Daniele

Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
> Hello,
> writing an extension library, I have a type only used to perform
> efficient in-place aggregation, but absolutely not to be used as a
> data type into a table (it contains pointers, so it would be a
> guaranteed crash).

> Is there a way to mark the type as non-storable?

Can you avoid making it a type at all? I think there are existing
examples of aggregates that just declare their state value as INTERNAL.

regards, tom lane

On Sat, Mar 26, 2011 at 10:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
>> Hello,
>> writing an extension library, I have a type only used to perform
>> efficient in-place aggregation, but absolutely not to be used as a
>> data type into a table (it contains pointers, so it would be a
>> guaranteed crash).
>
>> Is there a way to mark the type as non-storable?
>
> Can you avoid making it a type at all?  I think there are existing
> examples of aggregates that just declare their state value as INTERNAL.

I found no reference about this in the docs but yes, for instance
intagg is one of these.

However using it has not been straightforward: using the aggregate
defined with stype=internal I got the error "cannot accept a value of
type internal". I've found the error is raised by internal_in: that's
because the aggregate has an initcond defined - which however is only
a dummy to work around the error received in the agg definition in
case it is omitted: "must not omit initial value when transition
function is strict and transition type is not compatible with input
type"

I've made "internal" working by redefining the transition function as
non strict: this obviously has made its code a little bit more
complex, but it's probably better than having the internal type
exposed to the sql.

Thank you.

-- Daniele