Обсуждение: tsearch2api project
Hello 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 to create full dual interface to fulltext. Pavel I appreciate the comments
"Pavel Stehule" <pavel.stehule@gmail.com> 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 to create full dual interface to fulltext.
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.
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, but keep using the old API,
a compatibility module on pgfoundry seems to make sense.
We could alternatively put the migration support into a new
subdirectory named contrib/tsearch_migrate or something like that.
But I'm thinking tsearch2 is a good place because that's where
users of the old tsearch2 are likely to look.
Also, something that's not been addressed at all yet, AFAICS,
is providing a way to migrate an existing tsearch2 *configuration*
(as opposed to data or application code). I'm not sure there can
be any automatic way to do that, but at the very least we need
some documentation about what corresponds to what.
Comments?
regards, tom lane
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, but keep using the old API, > a compatibility module on pgfoundry seems to make sense. +1 > Also, something that's not been addressed at all yet, AFAICS, > is providing a way to migrate an existing tsearch2 *configuration* > (as opposed to data or application code). I'm not sure there can > be any automatic way to do that, but at the very least we need > some documentation about what corresponds to what. I'm afraid the defaults have "just worked" for me, so I never played with any of the config stuff (old or new)... I don't know if I'll be of any help here. -Andy
> > 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 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 solution with full compatibility. Maybe we can have second API, which isn't usable for loading of dump, but can be used for API compatibility. This API can be more cleaner and can be stored in contrib. else there are two points * load or trasformation dump * application's modification for new API > > 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, but keep using the old API, > a compatibility module on pgfoundry seems to make sense. > Migration is one true way. But I know lot of admins who are unable do it :( Pavel > We could alternatively put the migration support into a new > subdirectory named contrib/tsearch_migrate or something like that. > But I'm thinking tsearch2 is a good place because that's where > users of the old tsearch2 are likely to look. >
"Pavel Stehule" <pavel.stehule@gmail.com> 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 solution with full
> compatibility.
I think we are really going to have to tell people to use the removets2
script on their dumps in any case. I can't imagine that it'll be a good
idea to have a bogus tsvector type in the system -- it'll mess things
up going forward. I think probably the sort of solution you should be
after is1. load the compatibility module;2. load dump that's been stripped of old tsearch2 stuff;3. don't have to
changeanything else.
regards, tom lane
2007/10/17, Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> 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 solution with full
> > compatibility.
>
> I think we are really going to have to tell people to use the removets2
> script on their dumps in any case. I can't imagine that it'll be a good
> idea to have a bogus tsvector type in the system -- it'll mess things
> up going forward. I think probably the sort of solution you should be
> after is
> 1. load the compatibility module;
> 2. load dump that's been stripped of old tsearch2 stuff;
> 3. don't have to change anything else.
>
I agree.
@1 99% is done
I have question. Have I call directfunctioncallx interface for envelop fce?
If I don't modify any param from fce_info I can call directly wrapped function:
I used
#define ENVELOPE_FCE1(name,dest) \
Datum name (PG_FUNCTION_ARGS); \
PG_FUNCTION_INFO_V1(name); \
Datum \
name (PG_FUNCTION_ARGS) \
{ \ Datum arg0 = PG_GETARG_DATUM(0); \ return DirectFunctionCall1(dest, arg0); \
}
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); \
}
is it correct? or is better simple modify pg_proc? There is maybe
10-15 fce where is necessary do something
Pavel
"Pavel Stehule" <pavel.stehule@gmail.com> 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 are
several instances of that in the core code already.
I'd be more inclined to call the macro WRAPPER_FUNCTION, perhaps.
regards, tom lane