On Fri, 2007-06-15 at 10:36 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Although I'm happy to see tsearch finally hit the big time, I'm a bit
> > disappointed to see so many new datatype-specific SQL commands created.
>
> Per subsequent discussion we are down to just one
On Friday 15 June 2007 00:46, Oleg Bartunov wrote:
> On Thu, 14 Jun 2007, Tom Lane wrote:
> > [ thinks some more... ] If we revived the GENERATED AS patch,
> > you could imagine computing tsvector columns via "GENERATED AS
> > to_tsvector('english'::regconfig, big_text_col)" instead of a
> > trigg
On Thursday 14 June 2007 15:10, Teodor Sigaev wrote:
> That changes are doable for several days. I'd like to make changes together
> with replacing of FULLTEXT keyword to TEXT SEARCH as you suggested.
AIUI the discussion on this change took place off list? Can we get a preview
of what the comman
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Although I'm happy to see tsearch finally hit the big time, I'm a bit
> disappointed to see so many new datatype-specific SQL commands created.
Per subsequent discussion we are down to just one new set of commands,
CREATE/ALTER/DROP TEXT SEARCH CONFIGURA
On Wed, 2007-06-13 at 18:06 -0400, Bruce Momjian wrote:
> You bring up a very good point. There are fifteen new commands being
> added for full text indexing:
>
> alter-fulltext-config.sgml alter-fulltext-owner.sgml
> create-fulltext-dict.sgml drop-fulltext-dict.sgml
>
On Thu, 14 Jun 2007, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
You're correct. But we can't defend users from all possible errors.
Other side, that we need somehow to help user to identify what fts
configuration was used to produce tsvector. For example, comment on
tsvector colu
It should be. Instances of ispell (and synonym, thesaurus) dictionaries are
different only in dict_initoption part, so it will be only one entry in
pg_ts_dict_template and several ones in pg_ts_dict.
No, I was thinking of still having just one pg_ts_dict catalog (no template)
but removing its d
Michael Paesold <[EMAIL PROTECTED]> writes:
> After reading the discussion and the introduction, here is what I think
> tsearch in core should at least accomplish in 8.3.
> ...
> - Stop words in tables, not in external files.
I realized that there's a pretty serious problem with doing that, whi
"Oleg Bartunov" <[EMAIL PROTECTED]> writes:
> On Thu, 14 Jun 2007, Gregory Stark wrote:
>
>> Am I correct to think of this like changing collations leaving your btree
>> index "corrupt"? In that case it probably won't cause any backend crash
>> either
>> but you will get incorrect results. For ex
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>>> The reason to save SQLish interface to dictionaries is a simplicity of
>>> configuration. Snowball's stemmers are useful as is, but ispell dictionary
>>> requires some configuration action
Bruce Momjian wrote:
I an attempt to communicate what full text search does, and what
features we are thinking of adding/removing, I have put up the
introduction in HTML:
http://momjian.us/expire/fulltext/HTML/fulltext-intro.html
Very good idea, Bruce!
After reading the discussion an
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> You're correct. But we can't defend users from all possible errors.
> Other side, that we need somehow to help user to identify what fts
> configuration was used to produce tsvector. For example, comment on
> tsvector column would be useful, but we don'
Am I correct to think of this like changing collations leaving your btree
index "corrupt"? In that case it probably won't cause any backend crash either
but you will get incorrect results. For example, returning different results
depending on whether the index or a full table scan is used.
Witho
But, there are reasons to allow users register new templates and in fact
we know people/projects with application-dependent dictionaries. How
they could dump/reload their dictionaries ?
The same way as pg_am does.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
On Thu, 14 Jun 2007, Gregory Stark wrote:
"Teodor Sigaev" <[EMAIL PROTECTED]> writes:
But they still need some more thought about permissions, because AFAICS
mucking with a configuration can invalidate some other user's data.
ouch. could mucking with a configuration create a corrupt index?
On Thu, 14 Jun 2007, Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
The reason to save SQLish interface to dictionaries is a simplicity of
configuration. Snowball's stemmers are useful as is, but ispell dictionary
requires some configuration action before using.
Yeah. I had been w
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
The reason to save SQLish interface to dictionaries is a simplicity of
configuration. Snowball's stemmers are useful as is, but ispell dictionary
requires some configuration action before using.
Yeah. I had been wondering about movi
"Teodor Sigaev" <[EMAIL PROTECTED]> writes:
>>> But they still need some more thought about permissions, because AFAICS
>>> mucking with a configuration can invalidate some other user's data.
>>
>> ouch. could mucking with a configuration create a corrupt index?
>
> Depending on what you mean 'cor
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> The reason to save SQLish interface to dictionaries is a simplicity of
> configuration. Snowball's stemmers are useful as is, but ispell dictionary
> requires some configuration action before using.
Yeah. I had been wondering about moving the dict_ini
But they still need some more thought about permissions, because AFAICS
mucking with a configuration can invalidate some other user's data.
ouch. could mucking with a configuration create a corrupt index?
Depending on what you mean 'corrupted'. It will not corrupted as non-readable
or cause b
can we hard-code into the backend, and just update for every major
release like we do for encodings?
Sorry, no one of them :(. We know projects which introduce new parser, new
dictionary. Config and map are changes very often.
--
Teodor Sigaev E-mail: [EMAIL
Well assuming we have any SQL-level support at all I think we should
strive to avoid these functions taking INTERNAL arguments.
That gets us down to just needing to worry about whether we like the
SQL representation of configurations. Which is still a nontrivial
issue, but at least it seems ma
I an attempt to communicate what full text search does, and what
features we are thinking of adding/removing, I have put up the
introduction in HTML:
http://momjian.us/expire/fulltext/HTML/fulltext-intro.html
The links to the other sections don't work yet.
--
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Well my argument has always been the "core" feature argument. Perhaps I
am missing some info here, but when I read what you wrote, I read that
Tsearch will now be "harder" to work with. Not easier. :(
Then you misread it. What I w
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Well my argument has always been the "core" feature argument. Perhaps I
> am missing some info here, but when I read what you wrote, I read that
> Tsearch will now be "harder" to work with. Not easier. :(
Then you misread it. What I was proposing
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
O.k. I am not trying to throw any cold water on this, but with the
limitations we are suggesting, does the patch gain us anything over just
leaving tsearch in contrib?
Well, if you want to take a hard-nosed approach, no form of the
Joshua D. Drake wrote:
> Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> Well assuming we have any SQL-level support at all I think we should
> >> strive to avoid these functions taking INTERNAL arguments.
>
> > That gets us down to just needing to worry about whether we like th
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. I am not trying to throw any cold water on this, but with the
> limitations we are suggesting, does the patch gain us anything over just
> leaving tsearch in contrib?
Well, if you want to take a hard-nosed approach, no form of the patch
would
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
Well assuming we have any SQL-level support at all I think we should
strive to avoid these functions taking INTERNAL arguments.
That gets us down to just needing to worry about whether we like the
SQL representation of configurations.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well assuming we have any SQL-level support at all I think we should
> strive to avoid these functions taking INTERNAL arguments.
I don't think I want to get into redesigning the patch at that level of
detail, at least not for 8.3. It seems like somethi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> You could remove the immediate source of this objection if you could
> redesign the APIs for the underlying support functions to be more
> type-safe. I'm not sure how feasible or useful that would be though.
> The bottom-line question here is whether deve
You bring up a very good point. There are fifteen new commands being
added for full text indexing:
alter-fulltext-config.sgml alter-fulltext-owner.sgml
create-fulltext-dict.sgml drop-fulltext-dict.sgml
alter-fulltext-dict.sgmlalter-fulltext-parser.sgml
I've been looking at the tsearch patch a bit, and I think there needs to
be more thought given to the permissions required to mess around with
tsearch configuration objects.
The TSParser objects reference functions declared to take and return
INTERNAL arguments. This means that the underlying fun
33 matches
Mail list logo
