Re: tsearch in core patch, for inclusion - Mailing list pgsql-hackers

From Markus Schiltknecht
Subject Re: tsearch in core patch, for inclusion
Date
Msg-id 45DDCDC1.3090900@bluegap.ch
Whole thread Raw
In response to Re: tsearch in core patch, for inclusion  ("Pavel Stehule" <pavel.stehule@hotmail.com>)
Responses Re: tsearch in core patch, for inclusion  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: tsearch in core patch, for inclusion  (Peter Eisentraut <peter_e@gmx.net>)
List 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'snot 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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [Monotone-devel] Re: SCMS question
Next
From: "Joshua D. Drake"
Date:
Subject: Re: [Monotone-devel] Re: SCMS question