From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: External search engine, advice |
Date: | 2001-05-20 04:28:16 |
Message-ID: | 10237.990332896@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
mlw <markw(at)mohawksoft(dot)com> writes:
> The above is an example of how to write a function that returns multiple
> results.
One suggestion: you must check not only that fcinfo->resultinfo isn't
NULL, but that it points at the sort of node you're expecting. Say
if (fcinfo->resultinfo == NULL ||
! IsA(fcinfo->resultinfo, ReturnSetInfo))
<complain>;
If you fail to do this, you can fully expect your code to coredump
a version or two hence. Right now the only possibility for resultinfo
is to point at a ReturnSetInfo, but that *will* change.
> create function ftss_search (varchar)
> returns setof integer
> as '/usr/local/lib/library.so', 'ftss_search'
> language 'c' with (iscachable);
> The above in an example of how one would register this function in postgres.
Hmm ... given that ftss refers to external files, is it a good idea to
mark it cachable? I'd sort of expect that the values it returns for
a particular argument could change over time. Cachable amounts to a
promise that the results for a given argument will not change over time.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-20 04:30:08 | Re: Fix for tablename in targetlist |
Previous Message | Bruce Momjian | 2001-05-20 02:50:17 | Re: Fix for tablename in targetlist |