Skip to main content.
home | support | download

Back to List Archive

Re: pgswish - query swish-e index from PostgreSQL

From: Bill Moseley <moseley(at)>
Date: Sun Mar 06 2005 - 16:57:51 GMT
On Sun, Mar 06, 2005 at 05:42:58AM -0800, Dobrica Pavlinusic wrote:

Cool. So the advantage is that you can use your existing code (that
deals with results from a database) to do swish queries, correct?
I assume you can do joins on the table?

What's the idea/difference between pgswish and pgswish2?

> I'm interested about comments and success/failure stories if anybody is
> interested in using this extension.

Out of curiosity, I was trying to understand the code:

Is the index opened on every SELECT or just the very first time a
SELECT is issued?

Is there a way to get around having swish_handle, search,
search_results, and sw_res global?  What happens if you wanted to
search two indexes at the same time?  Or if you had a threaded

Should error_or_abort() return a value and then you SRF_RETURN_DONE()
based on that?

Maybe there should be multiple function for the different objects:
error_or_abort_(swish|search|results|result) calls -- I think you can
get the SW_HANDLE from each type of object to check for errors.

I've never been that happy with how the C API works compared to the
Perl xs code.  The perl code has the advantage that when variables go
out of scope (like by calling die or returning up the stack) that the
DESTROY methods will cascade cleaning up the parent objects.  If you
abort when working with a result then you really need to call
Free_Results_Object() followed by Free_Search_Object() and finally
SwishClose() (if it was a critical error).

So having multiple error_or_abort_* functions might make that easier.

The call SwishResultPropertyStr() is not really thread safe.  That may
not be a big deal for a number of reasons -- such as it being unlikely
that it would be used in a threaded application and that there may be
other overriding thread-unsafe code in swish-e core...

The "problem" is that SwishResultPropertyStr() looks up the property
value string and stores it in a common area of the parent DB_RESULTS
structure (which is shared by all indexes opened with SwishInit() ),
and the address of that cached string is returned.  So in a threaded
application the string might get changed by another thread during the
call to SwishResultPropertyStr().

The reason this is done is so that the calling application doesn't
need to worry about calling free() on the string.

If you look at perl/API.xs you will see that SwishProperty() (not
SwishResultPropertyStr() ) method calls a lower-level
getResultPropValue(), then copies the value into a Perl scalar (which
then Perl can worry about cleaning up) and then calls
freeResultPropValue(pv) to free the memory in swish before returning.

By the way, I like your coding style. ;)  Do you have any suggestions
for improving either the Swish-e C API docs or the API itself?

Bill Moseley

Unsubscribe from or help with the swish-e list:

Help with Swish-e:
Received on Sun Mar 6 08:58:03 2005