Re: feature request - datum_compute_size and datum write_should be public
От | Jim Nasby |
---|---|
Тема | Re: feature request - datum_compute_size and datum write_should be public |
Дата | |
Msg-id | 02401790-5497-4308-9B8B-1F54088752C9@nasby.net обсуждение исходный текст |
Ответ на | Re: feature request - datum_compute_size and datum write_should be public (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: feature request - datum_compute_size and datum write_should be public
|
Список | 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 intoa function and have the function tell me exactly how much space that would require on-disk. It's pretty easy to figurethat out for things like varchar and numeric, but doing so for arrays or composite types requires pretty detailed knowledgeof PG internals. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: