Thread: Full Text Search examples patch
I made some changes to textsearch.sgml, the FTS documentation. It contained references to a table 'pgweb' that was nowhere to be found, and a similarly unreferenced 'apod' table, which I happened to have found earlier here: http://www.sai.msu.su/~megera/postgres/fts/apod.dump.gz (it has around 1700 rows). I changed all references to 'pgweb' to 'apod'. This apod table initially corresponds with the structure of the table in the dump file. (In the documentation, that table is subsequently changed by adding a tsvector column.) It would be nice if that apod table could be included with postgres in its entirety, or maybe even an updated version, as the above dump only contains records from 1995-2001. In case the table is deemed to large for inclusion in the distribution, I have put the initial 'create' statements and selected 20 records, so that the example queries give some results (albeit fewer results than there are in the textsearch.sgml document now - it was apparently run with a full apod table). With these changes (from table 'pgweb' to 'apod') the examples can be run. If the table data is included (whole or truncated) a paragraph saying where to find it should be written too. Erik Rijkers
Attachment
"Erik" <er@xs4all.nl> writes:
> I changed all references to 'pgweb' to 'apod'. This apod
> table initially corresponds with the structure of the
> table in the dump file. (In the documentation, that table
> is subsequently changed by adding a tsvector column.)
Huh? These are just examples, they are not supposed to refer to any
specific real table, much less one that comes standard with Postgres.
regards, tom lane
Tom Lane wrote: > "Erik" <er@xs4all.nl> writes: >> I changed all references to 'pgweb' to 'apod'. This apod >> table initially corresponds with the structure of the >> table in the dump file. (In the documentation, that >> table >> is subsequently changed by adding a tsvector column.) > > Huh? These are just examples, they are not supposed to > refer to any > specific real table, much less one that comes standard > with Postgres. > > regards, tom lane I understand that, of course. I am suggesting it might be an improvement to offer the data to go with the examples. regards, Erik Rijkers
Erik wrote: > Tom Lane wrote: > > "Erik" <er@xs4all.nl> writes: > >> I changed all references to 'pgweb' to 'apod'. This apod > >> table initially corresponds with the structure of the > >> table in the dump file. (In the documentation, that > >> table > >> is subsequently changed by adding a tsvector column.) > > > > Huh? These are just examples, they are not supposed to > > refer to any > > specific real table, much less one that comes standard > > with Postgres. > > I understand that, of course. I am suggesting it might be > an improvement to offer the data to go with the examples. Hmm, wouldn't it be easier to provide the pgweb table? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Erik wrote: >> Tom Lane wrote: >> > "Erik" <er@xs4all.nl> writes: >> >> I changed all references to 'pgweb' to 'apod'. This >> apod >> >> table initially corresponds with the structure of the >> >> table in the dump file. (In the documentation, that >> >> table >> >> is subsequently changed by adding a tsvector column.) >> > >> > Huh? These are just examples, they are not supposed >> to >> > refer to any >> > specific real table, much less one that comes standard >> > with Postgres. >> >> I understand that, of course. I am suggesting it might >> be >> an improvement to offer the data to go with the >> examples. > > Hmm, wouldn't it be easier to provide the pgweb table? Maybe - I don't know what that pgweb data would be. There are really two issues: 1. Apply changes I suggested (and attached earlier) to the documentation text to make code examples use a single table instead of two different ones. I chose apod because I knew apod from tsearch2. In the patch there are also some confusing inconsistencies removed, for instance column 'textsearch_indexable_col' is in a later code example used as column 'textsearch'. 2. Whether or not to include some actual table data (be it apod or pgweb). This is less important as far as I am concerned. The first is more useful and easier to apply than the second. > Alvaro Herrera > http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, > 24x7 support > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by > donating at > > http://www.postgresql.org/about/donate > regards, Erik Rijkers
On Tue, 15 Jan 2008, Alvaro Herrera wrote:
> Erik wrote:
>> Tom Lane wrote:
>>> "Erik" <er@xs4all.nl> writes:
>>>> I changed all references to 'pgweb' to 'apod'. This apod
>>>> table initially corresponds with the structure of the
>>>> table in the dump file. (In the documentation, that
>>>> table
>>>> is subsequently changed by adding a tsvector column.)
>>>
>>> Huh? These are just examples, they are not supposed to
>>> refer to any
>>> specific real table, much less one that comes standard
>>> with Postgres.
>>
>> I understand that, of course. I am suggesting it might be
>> an improvement to offer the data to go with the examples.
>
> Hmm, wouldn't it be easier to provide the pgweb table?
probably, we could use one of the sample database from pgfoundry ?
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
Erik wrote:
> > Hmm, wouldn't it be easier to provide the pgweb table?
>
> Maybe - I don't know what that pgweb data would be.
>
> There are really two issues:
>
> 1. Apply changes I suggested (and attached earlier) to
> the documentation text to make code examples use a
> single table instead of two different ones. I chose
> apod because I knew apod from tsearch2. In the patch
> there are also some confusing inconsistencies removed,
> for instance column 'textsearch_indexable_col' is in a
> later code example used as column 'textsearch'.
>
> 2. Whether or not to include some actual table data (be
> it apod or pgweb). This is less important as far as I am
> concerned.
>
> The first is more useful and easier to apply than the
> second.
Agreed. The data file you sent was 1.5MB of data uncompressed. That
isn't going in the docs.
I looked at adding just the schema you had:
CREATE TABLE apod (
title text,
body text,
sdate date,
keywords text,
id integer
);
but later saw that there were 'apod' references later in the docs that
mentioned columns that weren't in the CREATE TABLE, e.g., 'vector':
SELECT * FROM ts_stat('SELECT vector FROM apod')
ORDER BY nentry DESC, ndoc DESC, word
LIMIT 10;
Please send a patch that adds the CREATE TABLE in a consistent manner
and we will consider just that addition. Here is where I suggest you
add the CREATE TABLE in the patch:
<programlisting>
CREATE TABLE apod (
title text,
body text,
sdate date,
keywords text,
id integer);
-- insert some data
SELECT title, ts_rank_cd(textsearch, query) AS rank
FROM apod, to_tsquery('neutrino|(dark & matter)') query
WHERE query @@ textsearch
ORDER BY rank DESC LIMIT 10;
I am fine with you updating the later examples to be more consistent
too.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +