Re: tsearch in core patch, for inclusion

From: Markus Schiltknecht <markus(at)bluegap(dot)ch>
To: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>
Cc: teodor(at)sigaev(dot)ru, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tsearch in core patch, for inclusion
Date: 2007-02-22 17:07:13
Message-ID: 45DDCDC1.3090900@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Pavel Stehule wrote:
> Functions maybe doesn't see efective, but user's cannot learn new syntax.

Are you serious? That argument speaks exactly *for* extending the
grammar. From other databases, users are used to:

CREATE TABLE ... (SQL)
CREATE INDEX ... (SQL)
CREATE FULLTEXT INDEX ... (Transact-SQL)
CREATE TABLE (... FULLTEXT ...) (MySQL)
CREATE INDEX ... INDEXTYPE IS ctxsys.context PARAMETERS ... (Oracle Text)

And users are constantly complaining that PostgreSQL doesn't have
fulltext indexing capabilities (if they don't know about tsearch2) or
about how hard it is to use tsearch2.

> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'],
> ARRAY['...']) is readable.

Hardly. Because it's not like SQL:

- it's counter-intuitive to have to SELECT, when you want to CREATE
something.
- it's confusing to have two actions (select create)
- why do I have to write ARRAYs to list parameters?
- it's not obvious what you're selecting (return value?)
- you have to keep track of the brackets, which can easily get messed
up with two levels of them. Especially if the command gets multiple
lines long.

> I agree so enhancing parser oabout not standard construct isn't good.

Generally? Wow! This would mean PostgreSQL would always lack behind
other RDBSes, regarding ease of use. Please don't do that!

Regards

Markus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-02-22 17:09:48 Re: [Monotone-devel] Re: SCMS question
Previous Message Andrew Dunstan 2007-02-22 17:03:30 Re: [Monotone-devel] Re: SCMS question