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 ?

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

Reply via email to