This patch provides a test case for libpq's row processor API.
contrib/dblink can deal with very large result sets by dumping them into
a tuplestore (which can spill to disk) --- but until now, the intermediate
storage of the query result in a PGresult meant memory bloat for any large
result. Now we use a row processor to convert the data to tuple form and
dump it directly into the tuplestore.
A limitation is that this only works for plain dblink() queries, not
dblink_send_query() followed by dblink_get_result(). In the latter
case we don't know the desired tuple rowtype soon enough. While hack
solutions to that are possible, a different user-level API would
probably be a better answer.
Kyotaro Horiguchi, reviewed by Marko Kreen and Tom Lane
<!-- doc/src/sgml/README.links -->
Linking within SGML documents can be confusing, so here is a summary:
Intra-document Linking
----------------------
<xref>
use to get chapter/section # from the title of the target
link, or xreflabel if defined at the target; has no close tag
http://www.oasis-open.org/docbook/documentation/reference/html/xref.html
<link>
use to supply text for the link, requires </link>
http://www.oasis-open.org/docbook/documentation/reference/html/link.html
linkend=
controls the target of the link/xref, required
endterm=
for <xref>, allows the text of the link/xref to be taken from a
different link target title
External Linking
----------------
<ulink>
like <link>, but uses a URL (not a document target); requires
</ulink>; if no text is specified, the URL appears as the link
text
http://www.oasis-open.org/docbook/documentation/reference/html/ulink.html
url=
used by <ulink> to specify the URL, required
Guidelines
----------
o If you want to supply text, use <link>, else <xref>
o Do not use text with <ulink> so the URL appears in printed output
o Specific nouns like GUC variables, SQL commands, and contrib modules
usually have xreflabels
6f922ef88e