Обсуждение: 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.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.
regards, tom lane
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
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
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 arrayinto a function and have the function tell me exactly how much space that would require on-disk. It's pretty easy tofigure that out for things like varchar and numeric, but doing so for arrays or composite types requires pretty detailedknowledge 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@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.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
arrayinto a function and have the function tell me exactly how much space that would require on-disk. It's pretty easy
tofigure that out for things like varchar and numeric, but doing so for arrays or composite types requires pretty
detailedknowledge 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