Re: [HACKERS] feature request - datum_compute_size and datum write_should be public
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 j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature request - datum_compute_size and datum write_should be public
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 alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature request - datum_compute_size and datum write_should be public
Alvaro Herrera alvhe...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature request - datum_compute_size and datum write_should be public
Pavel Stehule pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] feature request - datum_compute_size and datum write_should be public
2012/2/1 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
