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
Hi!
Now we (Oleg and me) are working on moving tsearch into core.
Pls, review suggested syntax. Comments, suggestions, objections will be
appreciated.
1) parser operation (pg_ts_parser table)
CREATE PARSER prsname (
START = funcname,
GETTOKEN = funcname,
END =
Teodor Sigaev [EMAIL PROTECTED] writes:
Now we (Oleg and me) are working on moving tsearch into core.
Pls, review suggested syntax. Comments, suggestions, objections will be
appreciated.
Is it really necessary to invent a batch of special-purpose commands?
Seems like this will add some
Hmm, IMHO, it's needed for consistent interface: nobody adds new column to table
by editing pg_class pg_attribute, nobody looks for description of table by
selection values from system table.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
Now we (Oleg and me) are working on moving
Teodor Sigaev wrote:
Hmm, IMHO, it's needed for consistent interface: nobody adds new
column to table by editing pg_class pg_attribute, nobody looks for
description of table by selection values from system table.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
Now we (Oleg and me)
On Fri, 17 Nov 2006, Andrew Dunstan wrote:
Teodor Sigaev wrote:
Hmm, IMHO, it's needed for consistent interface: nobody adds new column to
table by editing pg_class pg_attribute, nobody looks for description of
table by selection values from system table.
Tom Lane wrote:
Teodor Sigaev
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
Alvaro Herrera wrote:
We should also take the opportunity to discuss new keywords for the
XML support -- will we use new grammar, or functions?
The XML stuff is defined in the SQL standard and there are existing
implementations, so any nonstandard syntax is going to be significantly
less
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
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't see any comparable arguments about this full-text search stuff.
In particular I don't see any arguments why a change would necessary at
all, including why moving to core would be necessary in the first
place.
AFAIR the only argument in
On Fri, 17 Nov 2006, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't see any comparable arguments about this full-text search stuff.
In particular I don't see any arguments why a change would necessary at
all, including why moving to core would be necessary in the first
Alvaro Herrera [EMAIL PROTECTED] writes:
I also think the thousands of lines is an exaggeration :-)
I think a reasonable comparison point is the operator-class commands,
which are at least in the same general ballpark of complexity.
opclasscmds.c is currently 1075 lines, and that's not counting
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I also think the thousands of lines is an exaggeration :-)
I think a reasonable comparison point is the operator-class commands,
which are at least in the same general ballpark of complexity.
opclasscmds.c is currently 1075 lines,
On Fri, 17 Nov 2006, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't see any comparable arguments about this full-text search stuff.
In particular I don't see any arguments why a change would necessary at
all, including why moving to core would be necessary in the first
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It may be worth doing anyway --- certainly CREATE OPERATOR CLASS was a
huge improvement over the previous ways of doing it --- but don't
underestimate the size of what we're talking about.
Hmm, actually the tsearch2 directory contains
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't see any comparable arguments about this full-text search stuff.
In particular I don't see any arguments why a change would necessary at
all, including why moving to core would be necessary in the first
place.
AFAIR the
On 11/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
We should also take the opportunity to discuss new keywords for the
XML support -- will we use new grammar, or functions?
The XML stuff is defined in the SQL standard and there are existing
implementations, so any
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
Martijn van Oosterhout kleptog@svana.org writes:
On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
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?
Yeah, I worked with
Jeremy Drake wrote:
I am currently in the position that my hosting provider is
apprehensive about installing modules in contrib because they believe
they are less secure.
Using irrational and unfounded statements one can of course make
arguments for just about anything, but that won't help
Oleg Bartunov wrote:
marketing is not always swear-word :) We live in real world and
there are many situations where marketing is the deciding vote.
I don't know about you, but I market PostgreSQL partially using
1. sane design, not driven by random demands
2. extensibility
which would be
21 matches
Mail list logo
