From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, heikki(dot)linnakangas(at)iki(dot)fi, Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: feature request - datum_compute_size and datum write_should be public |
Date: | 2012-02-01 23:47:05 |
Message-ID: | 02401790-5497-4308-9B8B-1F54088752C9@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-02-01 23:48:28 | JSON output functions. |
Previous Message | Robert Haas | 2012-02-01 22:50:45 | spgist text_ops and LIKE |