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: (view raw, whole thread or download thread mbox)
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

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-2017 The PostgreSQL Global Development Group