|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/xtypes.sgml,v 1.28 2006/09/16 00:30:16 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/xtypes.sgml,v 1.29 2007/05/15 17:39:54 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <sect1 id="xtypes">
|
4 | 4 | <title>User-Defined Types</title>
|
@@ -237,20 +237,38 @@ CREATE TYPE complex (
|
237 | 237 | <primary>TOAST</primary>
|
238 | 238 | <secondary>and user-defined types</secondary>
|
239 | 239 | </indexterm>
|
240 |
| - If the values of your data type might exceed a few hundred bytes in |
241 |
| - size (in internal form), you should make the data type |
242 |
| - <acronym>TOAST</>-able (see <xref linkend="storage-toast">). |
243 |
| - To do this, the internal |
244 |
| - representation must follow the standard layout for variable-length |
245 |
| - data: the first four bytes must be an <type>int32</type> containing |
246 |
| - the total length in bytes of the datum (including itself). The C |
247 |
| - functions operating on the data type must be careful to unpack any |
| 240 | + If the values of your data type vary in size (in internal form), you should |
| 241 | + make the data type <acronym>TOAST</>-able (see <xref |
| 242 | + linkend="storage-toast">). You should do this even if the data are always |
| 243 | + too small to be compressed or stored externally because |
| 244 | + <productname>Postgres</> can save space on small data using |
| 245 | + <acronym>TOAST</> as well. |
| 246 | + </para> |
| 247 | + |
| 248 | + <para> |
| 249 | + To do this, the internal representation must follow the standard layout for |
| 250 | + variable-length data: the first four bytes must be an <type>int32</type> |
| 251 | + which is never accessed directly (customarily named <literal>vl_len_</>). You |
| 252 | + must use <function>SET_VARSIZE()</function> to store the size of the datum |
| 253 | + in this field and <function>VARSIZE()</function> to retrieve it. The C |
| 254 | + functions operating on the data type must always be careful to unpack any |
248 | 255 | toasted values they are handed, by using <function>PG_DETOAST_DATUM</>.
|
249 | 256 | (This detail is customarily hidden by defining type-specific
|
250 |
| - <function>GETARG</function> macros.) Then, |
251 |
| - when running the <command>CREATE TYPE</command> command, specify the |
252 |
| - internal length as <literal>variable</> and select the appropriate |
253 |
| - storage option. |
| 257 | + <function>GETARG_DATATYPE_P</function> macros.) Then, when running the |
| 258 | + <command>CREATE TYPE</command> command, specify the internal length as |
| 259 | + <literal>variable</> and select the appropriate storage option. |
| 260 | + </para> |
| 261 | + |
| 262 | + <para> |
| 263 | + If the alignment is unimportant (either just for a specific function or |
| 264 | + because the data type specifies byte alignment anyways) then it's possible |
| 265 | + to avoid some of the overhead of <function>PG_DETOAST_DATUM</>. You can use |
| 266 | + <function>PG_DETOAST_DATUM_PACKED</> instead (customarily hidden by |
| 267 | + defining a <function>GETARG_DATATYPE_PP</> macro) and using the macros |
| 268 | + <function>VARSIZE_ANY_EXHDR</> and <function>VARDATA_ANY</> macros. |
| 269 | + Again, the data returned by these macros is not aligned even if the data |
| 270 | + type definition specifies an alignment. If the alignment is important you |
| 271 | + must go through the regular <function>PG_DETOAST_DATUM</> interface. |
254 | 272 | </para>
|
255 | 273 |
|
256 | 274 | <para>
|
|
0 commit comments