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
---------------------------(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
