On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
> On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
> > > Having the supporting code in core does not make much of a difference
> > > otherwise from having it in contrib, does it?
> >
> > Given the nonextensibility of gram.y and keywords.c, it has to be in
> > core to even think about having special syntax :-(
>
> Has anyone ever heard of extensible grammers?

(not specifically answering Martijn...)

The main thought for me on this thread is: Why do we need to invent
*any* grammar to make this work? Why not just use functions?

For PITR we have pg_start_backup() rather than BACKUP START. For
advisory locks we have pg_advisory_lock()

What's wrong with having pg_tsearch_ functions to do everything? There's
nothing wrong with additional catalog tables/columns that are
manipulated by function calls only. We have that already - look at
pg_stat_reset() - no grammar stuff there.

Anybody with an Oracle or SQLServer background is used to seeing system
functions available as function calls; as I've observed above, so are
we. We should keep the grammar clean to allow a very close adherence to
SQL standards, IMHO.

I would like to see Oleg and Teodor's good work come into core, but I
don't want to see bucketfuls of new grammar issues.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Sat, 18 Nov 2006, Simon Riggs wrote:

> On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
>> On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
>>>> Having the supporting code in core does not make much of a difference
>>>> otherwise from having it in contrib, does it?
>>>
>>> Given the nonextensibility of gram.y and keywords.c, it has to be in
>>> core to even think about having special syntax :-(
>>
>> Has anyone ever heard of extensible grammers?
>
> (not specifically answering Martijn...)
>
> The main thought for me on this thread is: Why do we need to invent
> *any* grammar to make this work? Why not just use functions?
>
> For PITR we have pg_start_backup() rather than BACKUP START. For
> advisory locks we have pg_advisory_lock()
>
> What's wrong with having pg_tsearch_ functions to do everything? There's
> nothing wrong with additional catalog tables/columns that are
> manipulated by function calls only. We have that already - look at
> pg_stat_reset() - no grammar stuff there.
>
> Anybody with an Oracle or SQLServer background is used to seeing system
> functions available as function calls; as I've observed above, so are
> we. We should keep the grammar clean to allow a very close adherence to
> SQL standards, IMHO.
>
> I would like to see Oleg and Teodor's good work come into core, but I
> don't want to see bucketfuls of new grammar issues.

Summarizing, we have two questions -

1. Will tsearch comes to the core
2. Do we need grammar changes

I hope, we have consensus about 1. - we need fts as a core feature.
Second question is not very principal, that's why we asked -hackers.
So, if we'll not touch grammar, are there any issues with tsearch2 in core ?

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Oleg Bartunov wrote:
> So, if we'll not touch grammar, are there any issues with tsearch2 in
> core ?

Are there any issues with tsearch2 not in core?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Hi,

Peter Eisentraut wrote:
> Are there any issues with tsearch2 not in core?

I have run into troubles when restoring a dump, especially across
different versions of PostgreSQL and tsearch2. Mainly because pg_ts_*
are not system tables and thus need to be restored or installed separately.

And there still is the packaging issue which needs to be addressed. It's
not complicated, but a PITA to compile stemmers and setup custom
dictionaries.

What's really needed IMO is a clever packaging, including stemmers and
dictionaries for as many languages as we can come up with. So on a
debian system, it should become as simple as:

apt-get install postgresql-contrib-8.3
apt-get install postgresql-language-pack-english-8.3
apt-get install postgresql-language-pack-german-8.3
apt-get install postgresql-language-russian-german-8.3

Inclusion into core surely does not help with that.

Relabeling contrib to modules or extras or something would probably give
some people a warm fuzzy feeling when installing. OTOH, these are
probably the very same people who get excited about tsearch2 in core, so
if we want to satisfy them, we better put it right into core... I dunno.

Regards

Markus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Peter Eisentraut wrote:
> Oleg Bartunov wrote:
>> So, if we'll not touch grammar, are there any issues with tsearch2 in
>> core ?
>
> Are there any issues with tsearch2 not in core?
>


Quite apart from anything else, it really needs documentation of the
standard we give other core features.

I think if a feature will be of sufficiently general use it should be a
candidate for inclusion, and text search certainly comes within that
category in my mind.

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sat, 18 Nov 2006, Andrew Dunstan wrote:

> Peter Eisentraut wrote:
>> Oleg Bartunov wrote:
>>> So, if we'll not touch grammar, are there any issues with tsearch2 in
>>> core ?
>>
>> Are there any issues with tsearch2 not in core?
>>
>
>
> Quite apart from anything else, it really needs documentation of the
> standard we give other core features.


Sure. I just learned how to built (successfully) pg documentation and
researching on what's documentation standard. Should we need to write
separate full text search chapter and/or add description to relevant
chapters.

>
> I think if a feature will be of sufficiently general use it should be a
> candidate for inclusion, and text search certainly comes within that
> category in my mind.

It could helps us in Pg-MySQL discussions, at least, since we beat
mysql's fts

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Andrew Dunstan wrote:
> Peter Eisentraut wrote:
>> Oleg Bartunov wrote:
>>> So, if we'll not touch grammar, are there any issues with tsearch2 in
>>> core ?
>> Are there any issues with tsearch2 not in core?
>>
>
>
> Quite apart from anything else, it really needs documentation of the
> standard we give other core features.
>
> I think if a feature will be of sufficiently general use it should be a
> candidate for inclusion, and text search certainly comes within that
> category in my mind.

I agree here - full text search is of general use (and a very often
requested) feature - including it in core will both help us in marketing
postgresql (which should notbe seen as a "bad" thing at all) and more to
the point it provides an in-core user and showcase for two very powerful
and innovative technologies - GIST and GIN.


Stefan

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Alvaro Herrera wrote:
> Oleg Bartunov wrote:
>> On Fri, 17 Nov 2006, Andrew Dunstan wrote:
>
>>> I am also a bit concerned that the names of the proposed objects (parser,
>>> dictionary) don't convey their purpose adequately. Maybe TS_DICTIONARY and
>>> TS_PARSER might be better if we in fact need to name them.
>> this looks reasonable to me.
>
> Huh, but we don't use keywords with ugly abbreviations and underscores.
> How about "FULLTEXT DICTIONARY" and "FULLTEXT PARSER"? (Using
> "FULLTEXT" instead of "FULL TEXT" means you don't created common
> reserved words, and furthermore you don't collide with an existing type
> name.)

sounds fine

>
> I also think the "thousands of lines" is an exaggeration :-) The
> grammar should take a couple dozen at most. The rest of the code would
> go to their own files.
>
> We should also take the opportunity to discuss new keywords for the XML
> support -- will we use new grammar, or functions?
>

that is a good question and we should decide on a direction for that -
we already have a feature in shipping code that causes quite some
confusion in that regard(autovacuum).
What see I from supporting/consulting people is that there are more and
more people adapting autovacuum for there databases but those with
complex ones want to override them on a per table base.
We already provide a rather crude interface for that - namely manually
inserting some rows into a system table which is confusing the heck out
of people (they are either responding with "why is there now ALTER
AUTOVACUUM SET ..." or and equivalent pg_* function for that).
I'm not too sure what the most suitable interface for that would be but
finding a consistent solution for that might be good nevertheless.


Stefan

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate