Tom Lane wrote:
Anyway, the picture that's starting to emerge for me is that we
should repurpose contrib/tsearch2 as a repository for scripts
and documentation to help people migrate from previous use of
tsearch2 to use of the new core facilities; and for people who
want to try to *not* migrate,
Pavel Stehule [EMAIL PROTECTED] writes:
I created new project on pgfoundry. It's wrapper of integrated
fulltext and it's binary compatible with TSearch2 API.
* it works, (I am able load 82 dump without changes)
* it is ugly :( . I expected, so this wrapper can be more elegant, but
not. I had
Surely this shouldn't be creating its own tsvector datatype? Having
both public.tsvector and pg_catalog.tsvector seems like a seriously
bad idea, if only because of confusion. ISTM you should only be
creating new public.foo objects for the functions whose names changed.
I would to use
Pavel Stehule [EMAIL PROTECTED] writes:
Surely this shouldn't be creating its own tsvector datatype?
I would to use only pg_catalog.tsvector. But dump contains CREATE TYPE
statement, and custom functions which prefere it, because path is:
public, pg_catalog :(. I didn't find any other
2007/10/17, Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
Surely this shouldn't be creating its own tsvector datatype?
I would to use only pg_catalog.tsvector. But dump contains CREATE TYPE
statement, and custom functions which prefere it, because path is:
public,
Pavel Stehule [EMAIL PROTECTED] writes:
but I would
#define ENVELOPE_FCE(name,dest) \
Datum name (PG_FUNCTION_ARGS); \
PG_FUNCTION_INFO_V1(name); \
Datum \
name (PG_FUNCTION_ARGS) \
{ \
return (dest)(fceinfo); \
}
That seems perfectly legitimate to me --- I'm pretty sure there
