Обсуждение: 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

"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. +