mirror of https://github.com/postgres/postgres
Documentation updates to reflect TOAST and new-style fmgr.
This commit is contained in:
parent
0813fcbc08
commit
69cf335687
|
@ -509,12 +509,13 @@ trigf(PG_FUNCTION_ARGS)
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Now, compile and
|
||||
create table ttest (x int4):
|
||||
Now, compile and create the trigger function:
|
||||
|
||||
<programlisting>
|
||||
create function trigf () returns opaque as
|
||||
'...path_to_so' language 'c';
|
||||
'...path_to_so' language 'newC';
|
||||
|
||||
create table ttest (x int4);
|
||||
</programlisting>
|
||||
|
||||
<programlisting>
|
||||
|
|
|
@ -55,7 +55,7 @@ complex_in(char *str)
|
|||
double x, y;
|
||||
Complex *result;
|
||||
if (sscanf(str, " ( %lf , %lf )", &x, &y) != 2) {
|
||||
elog(NOTICE, "complex_in: error in parsing
|
||||
elog(ERROR, "complex_in: error in parsing %s", str);
|
||||
return NULL;
|
||||
}
|
||||
result = (Complex *)palloc(sizeof(Complex));
|
||||
|
@ -138,22 +138,16 @@ CREATE TYPE complex (
|
|||
<title>Large Objects</title>
|
||||
|
||||
<para>
|
||||
The types discussed to this point are all "small"
|
||||
objects -- that is, they are smaller than 8KB in size.
|
||||
<note>
|
||||
<para>
|
||||
1024 longwords == 8192 bytes. In fact, the type must be considerably smaller than 8192 bytes,
|
||||
since the <productname>Postgres</productname> tuple
|
||||
and page overhead must also fit into this 8KB limitation.
|
||||
The actual value that fits depends on the machine architecture.
|
||||
</para>
|
||||
</note>
|
||||
If you require a larger type for something like a document
|
||||
retrieval system or for storing bitmaps, you will
|
||||
need to use the <productname>Postgres</productname> large object
|
||||
interface, or will need to recompile the
|
||||
<productname>Postgres</productname> backend to use internal
|
||||
storage blocks greater than 8kbytes..
|
||||
If the values of your datatype might exceed a few hundred bytes in
|
||||
size (in internal form), you should be careful to mark them TOASTable.
|
||||
To do this, the internal representation must follow the standard
|
||||
layout for variable-length data: the first four bytes must be an int32
|
||||
containing the total length in bytes of the datum (including itself).
|
||||
Then, all your functions that accept values of the type must be careful
|
||||
to call pg_detoast_datum() on the supplied values --- after checking
|
||||
that the value is not NULL, if your function is not strict. Finally,
|
||||
select the appropriate storage option when giving the CREATE TYPE
|
||||
command.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
Loading…
Reference in New Issue