Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group