Thread: How to submit Tsearch V2 ?
Hi there, we still have no r/w access to CVS, so I'm asking authoritative developers to grab archive http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/tsearch-v2-stable.tar.gz and submit it to CVS for 7.4 beta. Please, completely remove old tsearch directory from contrib. Regards, Oleg PS. Marc, we hope to get an access to be able submit patches. _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
> we still have no r/w access to CVS, so I'm asking authoritative > developers to grab archive > http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/tsearch-v2-stable.tar.gz > and submit it to CVS for 7.4 beta. Out of interest - is it completely backwards compatible? Chris
On Thu, 3 Jul 2003, Oleg Bartunov wrote: > Marc, we hope to get an access to be able submit patches. I sent back a note to Teodor earlier this evening letting him know that I think I got the password issue fixed with CVS, but asked him to test and get back to me ...
On Fri, 4 Jul 2003, Christopher Kings-Lynne wrote: > > we still have no r/w access to CVS, so I'm asking authoritative > > developers to grab archive > > > http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/tsearch-v2-stable.tar.gz > > and submit it to CVS for 7.4 beta. > > Out of interest - is it completely backwards compatible? unfortunately, no > > Chris > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
> > > we still have no r/w access to CVS, so I'm asking authoritative > > > developers to grab archive > > > > > http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/tsearch-v2-stable.tar.gz > > > and submit it to CVS for 7.4 beta. > > > > Out of interest - is it completely backwards compatible? > > unfortunately, no Then surely fully replacing tsearch will cause badness? Chris
On Fri, 4 Jul 2003, Christopher Kings-Lynne wrote: > > > > we still have no r/w access to CVS, so I'm asking authoritative > > > > developers to grab archive > > > > > > > > http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/tsearch-v2-stable.tar.gz > > > > and submit it to CVS for 7.4 beta. > > > > > > Out of interest - is it completely backwards compatible? > > > > unfortunately, no > > Then surely fully replacing tsearch will cause badness? I see, so are you suggesting separate dir for tsearch v2 ? > > Chris > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
> > > > Out of interest - is it completely backwards compatible? > > > > > > unfortunately, no > > > > Then surely fully replacing tsearch will cause badness? > > I see, so are you suggesting separate dir for tsearch v2 ? Well, we use tserach 1 extensively. I want to be able to upgrade to 7.4 and have nothing break! If things will break, then you need to have a tsearch2 dir instead. Chris
I think with upgrade X.Y to X.Y+1 version of pgsql you need dump/restore all
databases, isn't it?
So, for upgrading tsearch to V2 you need to do following:
1 rename columns or typecast for type txtidx to tsvector, query_txt to tsquery
2 rename function txt2txtidx to to_tsvector, ( may be to strip(to_tsvector()), now tsvector has information for
ranking), trigger 'tsearch' isn't changed
3 operator class (in create index command) gist_txtidx_ops to gist_tsvector_ops
4 In queries: operator ## to @@ to_tsquery() and remove mquery_txt typecast
5 If your locale of pgsql differ from 'C', execute before first query select set_curcfg('default');
That's all. So upgrade from v1 to v2 isn't difficult.
Christopher Kings-Lynne wrote:
>>>>>Out of interest - is it completely backwards compatible?
>>>>
>>>>unfortunately, no
>>>
>>>Then surely fully replacing tsearch will cause badness?
>>
>>I see, so are you suggesting separate dir for tsearch v2 ?
>
>
> Well, we use tserach 1 extensively. I want to be able to upgrade to 7.4 and
> have nothing break!
>
> If things will break, then you need to have a tsearch2 dir instead.
>
> Chris
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Teodor Sigaev E-mail: teodor@sigaev.ru
Chris,
what if we write, that old tsearch (v1) is deprecated in 7.4 and will be
obsoleted in 7.5 and put tsearch-v1.tar.gz on our site.
Oleg
On Fri, 4 Jul 2003, Teodor Sigaev wrote:
> I think with upgrade X.Y to X.Y+1 version of pgsql you need dump/restore all
> databases, isn't it?
>
> So, for upgrading tsearch to V2 you need to do following:
> 1 rename columns or typecast for type txtidx to tsvector, query_txt to tsquery
> 2 rename function txt2txtidx to to_tsvector, ( may be to strip(to_tsvector()),
> now tsvector has information for ranking ), trigger 'tsearch' isn't changed
> 3 operator class (in create index command) gist_txtidx_ops to gist_tsvector_ops
> 4 In queries: operator ## to @@ to_tsquery() and remove mquery_txt typecast
> 5 If your locale of pgsql differ from 'C', execute before first query
> select set_curcfg('default');
>
> That's all. So upgrade from v1 to v2 isn't difficult.
>
>
>
> Christopher Kings-Lynne wrote:
> >>>>>Out of interest - is it completely backwards compatible?
> >>>>
> >>>>unfortunately, no
> >>>
> >>>Then surely fully replacing tsearch will cause badness?
> >>
> >>I see, so are you suggesting separate dir for tsearch v2 ?
> >
> >
> > Well, we use tserach 1 extensively. I want to be able to upgrade to 7.4 and
> > have nothing break!
> >
> > If things will break, then you need to have a tsearch2 dir instead.
> >
> > Chris
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
> So, for upgrading tsearch to V2 you need to do following:
> 1 rename columns or typecast for type txtidx to tsvector, query_txt to tsquery
> 2 rename function txt2txtidx to to_tsvector, ( may be to strip(to_tsvector()),
> now tsvector has information for ranking ), trigger 'tsearch' isn't changed
> 3 operator class (in create index command) gist_txtidx_ops to gist_tsvector_ops
> 4 In queries: operator ## to @@ to_tsquery() and remove mquery_txt typecast
> 5 If your locale of pgsql differ from 'C', execute before first query
> select set_curcfg('default');
>
> That's all. So upgrade from v1 to v2 isn't difficult.
And you expect thousands of users to do this? I don't know about that...
I can barely handle it myself, and I was looking forward to a Postgres
upgrade for a change where I didn't have to edit the dump :(
Chris
Well, I doubt what is right way.
tsearch V2 use new names, new function new feature and hasn't compatibility with
old one.
1 tsearch2 and tsearch directory in contrib. tsearch marked as deprecated and
will be removed for 7.5
2 V2 places in contrib as tsearch, old tsearch will be at our site.
It seems to me that second way is correcter way. Two version of tsearch is
surplus...
What do people think about it?
Christopher Kings-Lynne wrote:
>>So, for upgrading tsearch to V2 you need to do following:
>>1 rename columns or typecast for type txtidx to tsvector, query_txt to tsquery
>>2 rename function txt2txtidx to to_tsvector, ( may be to strip(to_tsvector()),
>> now tsvector has information for ranking ), trigger 'tsearch' isn't changed
>>3 operator class (in create index command) gist_txtidx_ops to gist_tsvector_ops
>>4 In queries: operator ## to @@ to_tsquery() and remove mquery_txt typecast
>>5 If your locale of pgsql differ from 'C', execute before first query
>> select set_curcfg('default');
>>
>>That's all. So upgrade from v1 to v2 isn't difficult.
>
>
> And you expect thousands of users to do this? I don't know about that...
>
> I can barely handle it myself, and I was looking forward to a Postgres
> upgrade for a change where I didn't have to edit the dump :(
>
> Chris
>
--
Teodor Sigaev E-mail: teodor@sigaev.ru
Chris,
would be the right solution to make tsearch V2 to be fully incompatible
with old tsearch (so both version could live in one database) and
release tsearch v2 in separate directory. This way require some additional
work but would not confuse people. As a bonus, people could start playing
with new tsearch V2 very easy.
We need "the right wordings" in README.tsearch of old tsearch to
warn people that old tsearch is deprecated and will be obsoleted in the next
release of PostgreSQL.
Teodor, how it'd be difficult ?
Oleg
On Fri, 4 Jul 2003, Teodor Sigaev wrote:
> Well, I doubt what is right way.
>
> tsearch V2 use new names, new function new feature and hasn't compatibility with
> old one.
>
> 1 tsearch2 and tsearch directory in contrib. tsearch marked as deprecated and
> will be removed for 7.5
> 2 V2 places in contrib as tsearch, old tsearch will be at our site.
>
>
> It seems to me that second way is correcter way. Two version of tsearch is
> surplus...
>
> What do people think about it?
>
>
> Christopher Kings-Lynne wrote:
> >>So, for upgrading tsearch to V2 you need to do following:
> >>1 rename columns or typecast for type txtidx to tsvector, query_txt to tsquery
> >>2 rename function txt2txtidx to to_tsvector, ( may be to strip(to_tsvector()),
> >> now tsvector has information for ranking ), trigger 'tsearch' isn't changed
> >>3 operator class (in create index command) gist_txtidx_ops to gist_tsvector_ops
> >>4 In queries: operator ## to @@ to_tsquery() and remove mquery_txt typecast
> >>5 If your locale of pgsql differ from 'C', execute before first query
> >> select set_curcfg('default');
> >>
> >>That's all. So upgrade from v1 to v2 isn't difficult.
> >
> >
> > And you expect thousands of users to do this? I don't know about that...
> >
> > I can barely handle it myself, and I was looking forward to a Postgres
> > upgrade for a change where I didn't have to edit the dump :(
> >
> > Chris
> >
>
>
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
> would be the right solution to make tsearch V2 to be fully incompatible > with old tsearch (so both version could live in one database) and > release tsearch v2 in separate directory. This way require some additional > work but would not confuse people. As a bonus, people could start playing > with new tsearch V2 very easy. That seems like the best way. I guess what we need to do is build it in to Postgres at some point, so people won't have these problems... Chris
On Mon, 7 Jul 2003, Christopher Kings-Lynne wrote: > > would be the right solution to make tsearch V2 to be fully incompatible > > with old tsearch (so both version could live in one database) and > > release tsearch v2 in separate directory. This way require some additional > > work but would not confuse people. As a bonus, people could start playing > > with new tsearch V2 very easy. > > That seems like the best way. > Chris, please download and test new version of tsearch2 module (note, '2' ) from http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ It should be now fully incompatible with old tsearch module. I've checked only functionality, because I have no old tsearch installation. So, please, check if the new version will not clashes with old tsearch. > I guess what we need to do is build it in to Postgres at some point, so > people won't have these problems... Oh, yes. But we have to find out how to write more flexible parser which should be locale aware and have unicode support. Also, we need more flexible parser<->dictionary interaction. A lot of things to think :) > > Chris > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
I am inclinded to replace /contrib/tsearch with the new version, V2, and tell people who want to keep the old version to just use the 7.3.X sources in 7.4. If we ship both versions in 7.4, we then have to rename tsearch2 to tsearch in 7.5, and that is pretty confusing. --------------------------------------------------------------------------- Oleg Bartunov wrote: > On Mon, 7 Jul 2003, Christopher Kings-Lynne wrote: > > > > would be the right solution to make tsearch V2 to be fully incompatible > > > with old tsearch (so both version could live in one database) and > > > release tsearch v2 in separate directory. This way require some additional > > > work but would not confuse people. As a bonus, people could start playing > > > with new tsearch V2 very easy. > > > > That seems like the best way. > > > > Chris, > > please download and test new version of tsearch2 module (note, '2' ) > from http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ > It should be now fully incompatible with old tsearch module. > I've checked only functionality, because I have no old tsearch installation. > So, please, check if the new version will not clashes with old tsearch. > > > I guess what we need to do is build it in to Postgres at some point, so > > people won't have these problems... > > Oh, yes. But we have to find out how to write more flexible parser which > should be locale aware and have unicode support. Also, we need more > flexible parser<->dictionary interaction. A lot of things to think :) > > > > > > > Chris > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --------------------------------------------------------------------------- Oleg Bartunov wrote: > On Mon, 7 Jul 2003, Christopher Kings-Lynne wrote: > > > > would be the right solution to make tsearch V2 to be fully incompatible > > > with old tsearch (so both version could live in one database) and > > > release tsearch v2 in separate directory. This way require some additional > > > work but would not confuse people. As a bonus, people could start playing > > > with new tsearch V2 very easy. > > > > That seems like the best way. > > > > Chris, > > please download and test new version of tsearch2 module (note, '2' ) > from http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ > It should be now fully incompatible with old tsearch module. > I've checked only functionality, because I have no old tsearch installation. > So, please, check if the new version will not clashes with old tsearch. > > > I guess what we need to do is build it in to Postgres at some point, so > > people won't have these problems... > > Oh, yes. But we have to find out how to write more flexible parser which > should be locale aware and have unicode support. Also, we need more > flexible parser<->dictionary interaction. A lot of things to think :) > > > > > > > Chris > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Sunday, July 20, 2003 14:18:05 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > I am inclinded to replace /contrib/tsearch with the new version, V2, and > tell people who want to keep the old version to just use the 7.3.X > sources in 7.4. I disagree here. There is a MIGRATION necessary, and people using packaging systems like FreeBSD Ports may not have the ability to use the 7.3.x tarball to get it right. > > If we ship both versions in 7.4, we then have to rename tsearch2 to > tsearch in 7.5, and that is pretty confusing. No, you keep it named tsearch2 forever, and drop tsearch at some future time. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Bruce, we've already found a solution - the same as Larry wrote. tsearch v1 is deprecated in 7.4 and obsoleted in 7.5 (I think this should be written in Changes or History). Anyway, I hope we'll integrate tsearch2 into core and tsearch2 will dissapeared :) btw, we've got CVS access, so we'll submit tsearch2. Oleg On Sun, 20 Jul 2003, Larry Rosenman wrote: > > > --On Sunday, July 20, 2003 14:18:05 -0400 Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > > > > > I am inclinded to replace /contrib/tsearch with the new version, V2, and > > tell people who want to keep the old version to just use the 7.3.X > > sources in 7.4. > I disagree here. There is a MIGRATION necessary, and people using > packaging systems > like FreeBSD Ports may not have the ability to use the 7.3.x tarball to get > it right. > > > > > > If we ship both versions in 7.4, we then have to rename tsearch2 to > > tsearch in 7.5, and that is pretty confusing. > No, you keep it named tsearch2 forever, and drop tsearch at some future > time. > > > > > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Oh, OK, great. You should probably move tsearch/ to tsearch1/. --------------------------------------------------------------------------- Oleg Bartunov wrote: > Bruce, > > we've already found a solution - the same as Larry wrote. > tsearch v1 is deprecated in 7.4 and obsoleted in 7.5 > (I think this should be written in Changes or History). > Anyway, I hope we'll integrate tsearch2 into core and > tsearch2 will dissapeared :) > > btw, we've got CVS access, so we'll submit tsearch2. > > Oleg > On Sun, 20 Jul 2003, Larry Rosenman wrote: > > > > > > > --On Sunday, July 20, 2003 14:18:05 -0400 Bruce Momjian > > <pgman@candle.pha.pa.us> wrote: > > > > > > > > I am inclinded to replace /contrib/tsearch with the new version, V2, and > > > tell people who want to keep the old version to just use the 7.3.X > > > sources in 7.4. > > I disagree here. There is a MIGRATION necessary, and people using > > packaging systems > > like FreeBSD Ports may not have the ability to use the 7.3.x tarball to get > > it right. > > > > > > > > > > If we ship both versions in 7.4, we then have to rename tsearch2 to > > > tsearch in 7.5, and that is pretty confusing. > > No, you keep it named tsearch2 forever, and drop tsearch at some future > > time. > > > > > > > > > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Patch removed from queue --- Oleg will apply. --------------------------------------------------------------------------- Oleg Bartunov wrote: > On Mon, 7 Jul 2003, Christopher Kings-Lynne wrote: > > > > would be the right solution to make tsearch V2 to be fully incompatible > > > with old tsearch (so both version could live in one database) and > > > release tsearch v2 in separate directory. This way require some additional > > > work but would not confuse people. As a bonus, people could start playing > > > with new tsearch V2 very easy. > > > > That seems like the best way. > > > > Chris, > > please download and test new version of tsearch2 module (note, '2' ) > from http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ > It should be now fully incompatible with old tsearch module. > I've checked only functionality, because I have no old tsearch installation. > So, please, check if the new version will not clashes with old tsearch. > > > I guess what we need to do is build it in to Postgres at some point, so > > people won't have these problems... > > Oh, yes. But we have to find out how to write more flexible parser which > should be locale aware and have unicode support. Also, we need more > flexible parser<->dictionary interaction. A lot of things to think :) > > > > > > > Chris > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073