Re: feature request - datum_compute_size and datum write_should be public - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: feature request - datum_compute_size and datum write_should be public
Date
Msg-id CAFj8pRBCgXoOvxvRNQH=aXrO4DeEpd4rbZMw6kivcnLS46=QQQ@mail.gmail.com
Whole thread Raw
In response to Re: feature request - datum_compute_size and datum write_should be public  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: feature request - datum_compute_size and datum write_should be public
List pgsql-hackers
2012/2/1 Tom Lane <tgl@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> I looked to sources and I found a some useful routines for people who
>> write extensions and probably PL too.
>
>> There are datum_compute_size and datum_write from range_types.c. These
>> routines can be used in PL libs and maybe in other places.
>
>> Should be these routines moved to varlena.c and be public?
>
> Why?  It is not common for types to contain other types, and it
> certainly isn't likely to happen without needing lots of other
> infrastructure --- the existing examples are arrays, records, and
> rangetypes, and all of those come with lots of baggage.  And there
> are a number of choices in those functions that are pretty specific to
> rangetypes, as illustrated by the fact that they're not already sharing
> code with either arrays or records.

For example I can use this code in my implementation of set of enum
(enumset datatype) because I have to wrap a array sometimes (I reuse a
array infrastructure).

In orafce I can use this code for serialisation and deserialisation
Datums - it is used more times there

Pavel

>
>                        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: feature request - datum_compute_size and datum write_should be public
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Speed dblink using alternate libpq tuple storage