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
Andrew Dunstan wrote:
> Peter Eisentraut wrote:
>> Oleg Bartunov wrote:
>>> So, if we'll not touch grammar, are there any issues with tsearch2 in
>>> core ?
>> Are there any issues with tsearch2 not in core?
>>
>
>
> Quite apart from anything else, it really needs documentation of the
> standard
On Sat, 18 Nov 2006, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Oleg Bartunov wrote:
So, if we'll not touch grammar, are there any issues with tsearch2 in
core ?
Are there any issues with tsearch2 not in core?
Quite apart from anything else, it really needs documentation of the
standa
Peter Eisentraut wrote:
> Oleg Bartunov wrote:
>> So, if we'll not touch grammar, are there any issues with tsearch2 in
>> core ?
>
> Are there any issues with tsearch2 not in core?
>
Quite apart from anything else, it really needs documentation of the
standard we give other core features.
I thi
> --- Original Message ---
> From: Peter Eisentraut <[EMAIL PROTECTED]>
> To: Jeremy Drake <[EMAIL PROTECTED]>
> Sent: 18/11/06, 07:30:48
> Subject: Re: [HACKERS] Proposal: syntax of operation with tsearch's
> configuration
>
> Jeremy Drake
Hi,
Peter Eisentraut wrote:
Are there any issues with tsearch2 not in core?
I have run into troubles when restoring a dump, especially across
different versions of PostgreSQL and tsearch2. Mainly because pg_ts_*
are not system tables and thus need to be restored or installed separately.
An
Oleg Bartunov wrote:
> So, if we'll not touch grammar, are there any issues with tsearch2 in
> core ?
Are there any issues with tsearch2 not in core?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 3: Have
On Sat, 18 Nov 2006, Simon Riggs wrote:
On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
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 non
On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
> 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
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
28 matches
Mail list logo
