Re: Non-storable data type

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Non-storable data type
Date: 2011-03-27 00:09:08
Message-ID: AANLkTikwpt1MyYT-DOJZUhdo0ZHtKpr6H7HHevVZoMqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Zheng Yang 2011-03-27 12:51:21 Re: foreign data wrappers
Previous Message Tom Lane 2011-03-26 22:35:01 Re: Non-storable data type