Re: feature request - datum_compute_size and datum write_should be public

Hello

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?

Regards

Pavel

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.

regards, tom lane

2012/2/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

On Feb 1, 2012, at 12:45 AM, Pavel Stehule wrote:
>>> 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

I'm not certain this in what Pavel is referring to, but I have often wished that I could pass something like an array into a function and have the function tell me exactly how much space that would require on-disk. It's pretty easy to figure that out for things like varchar and numeric, but doing so for arrays or composite types requires pretty detailed knowledge of PG internals.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

Excerpts from Jim Nasby's message of mié feb 01 20:47:05 -0300 2012:

> I'm not certain this in what Pavel is referring to, but I have often wished that I could pass something like an array into a function and have the function tell me exactly how much space that would require on-disk. It's pretty easy to figure that out for things like varchar and numeric, but doing so for arrays or composite types requires pretty detailed knowledge of PG internals.

I think you can just use pg_column_size on a composite datum (such as a
ROW() construct) and it will give you the right number.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Jim Nasby's message of mi feb 01 20:47:05 -0300 2012:
>> I'm not certain this in what Pavel is referring to, but I have often wished that I could pass something like an array into a function and have the function tell me exactly how much space that would require on-disk. It's pretty easy to figure that out for things like varchar and numeric, but doing so for arrays or composite types requires pretty detailed knowledge of PG internals.

> I think you can just use pg_column_size on a composite datum (such as a
> ROW() construct) and it will give you the right number.

If it's a freshly-computed value, pg_column_size will give you the size
of the "raw" datum. The actual size on disk might be less due to
compression, but I don't think we give you any way to find that out
short of actually storing it in a table. Note that the rangetype
internal functions Pavel suggests we should expose won't give you the
latter either.

regards, tom lane