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 ne
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
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
Martijn van Oosterhout 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 systems tha
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 s
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
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.
>
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
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
pla
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
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 count
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 th
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
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 t
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 use
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 loo
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 <[
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 m
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 movi
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 th
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 = funcnam
21 matches
Mail list logo
