On Tue, 14 Aug 2007, Alvaro Herrera wrote:
Oleg Bartunov wrote:
On Tue, 14 Aug 2007, Alvaro Herrera wrote:
Oleg Bartunov wrote:
On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a column/index thatn to th
On 8/14/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Mike Rylander" <[EMAIL PROTECTED]> writes:
>
> > My application (http://open-ils.org, which run >80% of the public
> > libraries in Georgia, USA, http://gapines.org and
> > http://georgialibraries.org/lib/pines.html) requires that I be able to
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Bruce Momjian escribi?:
> >> What has really hurt the default GUC idea is how to do restores from a
> >> pg_dump.
>
> > I guess what should happen is that pg_dump should include a
> > SET default_text_search_config = 'foo'
> > just b
"Mike Rylander" <[EMAIL PROTECTED]> writes:
> My application (http://open-ils.org, which run >80% of the public
> libraries in Georgia, USA, http://gapines.org and
> http://georgialibraries.org/lib/pines.html) requires that I be able to
> search a corpus of bibliographic records in a mix of langua
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian escribió:
>> What has really hurt the default GUC idea is how to do restores from a
>> pg_dump.
> I guess what should happen is that pg_dump should include a
> SET default_text_search_config = 'foo'
> just before the CREATE INDEX, like we
On 8/14/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Oleg Bartunov wrote:
> > On Tue, 14 Aug 2007, Alvaro Herrera wrote:
> >
> >> Oleg Bartunov wrote:
> >>> On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
> >>>
> Maybe I'm missing something, but it seems to me that the configuration
> is
Oleg Bartunov wrote:
> On Tue, 14 Aug 2007, Alvaro Herrera wrote:
>
>> Oleg Bartunov wrote:
>>> On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
>>>
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a column/index thatn to the whole database. If
t
Bruce Momjian escribió:
> Mike Rylander wrote:
> > This is just my $0.02 as a fairly heavy user of the current tsearch2
> > code, but I sincerely hope you do not cripple the system by removing
> > the ability to store tsvectors built using arbitrary configurations in
> > a single column. Yes, it c
Mike Rylander wrote:
> This is just my $0.02 as a fairly heavy user of the current tsearch2
> code, but I sincerely hope you do not cripple the system by removing
> the ability to store tsvectors built using arbitrary configurations in
> a single column. Yes, it can lead to unexpected results if y
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Heikki Linnakangas wrote:
> >> Bruce Momjian wrote:
> >>> Heikki Linnakangas wrote:
> Removing the default configuration setting altogether removes the 2nd
> problem, but that's not good from a usability point of view. And it
> doe
On 8/14/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Mike Rylander wrote:
[snip]
>
> Don't you need to use the right configuration to parse the query into a
> tsquery as well?
>
Only if the user (or user agent) can supply enough information to move
away from the configured default of, say,
On Tue, 14 Aug 2007, Alvaro Herrera wrote:
Oleg Bartunov wrote:
On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a column/index thatn to the whole database. If
there's a default in an expression, I'd rather
Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> Bruce Momjian wrote:
>>> Heikki Linnakangas wrote:
Removing the default configuration setting altogether removes the 2nd
problem, but that's not good from a usability point of view. And it
doesn't solve the general issue, you can st
Mike Rylander wrote:
> This is just my $0.02 as a fairly heavy user of the current tsearch2
> code, but I sincerely hope you do not cripple the system by removing
> the ability to store tsvectors built using arbitrary configurations in
> a single column. Yes, it can lead to unexpected results if y
On 8/13/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Heikki Linnakangas wrote:
> > Bruce Momjian wrote:
> > > Heikki Linnakangas wrote:
> > >> Removing the default configuration setting altogether removes the 2nd
> > >> problem, but that's not good from a usability point of view. And it
> > >> do
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Oleg Bartunov wrote:
>>
>> I'm tired to repeat - index itself doesn't know about configuration !
>
> Is there a way to change that? For example store the configuration in a
> metapage or something?
I think Heikki's suggestion of having each configu
Oleg Bartunov wrote:
> On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
>
>> Maybe I'm missing something, but it seems to me that the configuration
>> is more attached to a column/index thatn to the whole database. If
>> there's a default in an expression, I'd rather expect this default to be
>> drawn
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Heikki Linnakangas wrote:
> >> Removing the default configuration setting altogether removes the 2nd
> >> problem, but that's not good from a usability point of view. And it
> >> doesn't solve the general issue, you can still do things like:
> >>
Heikki Linnakangas wrote:
> Oleg Bartunov wrote:
> > On Wed, 8 Aug 2007, Bruce Momjian wrote:
> >> Heikki Linnakangas wrote:
> >>> If I understood correctly, the basic issue is that a tsvector datum
> >>> created using configuration A is incompatible with a tsquery datum
> >>> created using configu
Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> Removing the default configuration setting altogether removes the 2nd
>> problem, but that's not good from a usability point of view. And it
>> doesn't solve the general issue, you can still do things like:
>> SELECT * FROM foo WHERE to_tsvector('
Oleg Bartunov wrote:
> On Wed, 8 Aug 2007, Bruce Momjian wrote:
>> Heikki Linnakangas wrote:
>>> If I understood correctly, the basic issue is that a tsvector datum
>>> created using configuration A is incompatible with a tsquery datum
>>> created using configuration B, in the sense that you won't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Aug 09, 2007 at 02:03:13PM +0400, Oleg Bartunov wrote:
> On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
>
> >Maybe I'm missing something [...]
> I'm tired to repeat - index itself doesn't know about configuration !
> It just index tsvector data
On Thu, 9 Aug 2007, [EMAIL PROTECTED] wrote:
Maybe I'm missing something, but it seems to me that the configuration
is more attached to a column/index thatn to the whole database. If
there's a default in an expression, I'd rather expect this default to be
drawn from the index involved than from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Aug 09, 2007 at 02:36:41AM -0400, Bruce Momjian wrote:
> Oleg Bartunov wrote:
> > > Yea, seems more work than is necessary. If we require the configuration
> > > to be always supplied, and document that mismatches are a problem, I
> > > think
Oleg Bartunov wrote:
> > Yea, seems more work than is necessary. If we require the configuration
> > to be always supplied, and document that mismatches are a problem, I
> > think we are in good shape.
>
> We should agree that all you describe is only for DUMMY users.
> >From authors point of vi
On Wed, 8 Aug 2007, Bruce Momjian wrote:
Heikki Linnakangas wrote:
Sure, but you have make sure you use the right configuration in the
trigger, no? Does the tsquery have to use the same configuration?
I wish I knew this myself. :-) Whatever I had done happened to work
but that was largely t
Heikki Linnakangas wrote:
> >>> Sure, but you have make sure you use the right configuration in the
> >>> trigger, no? Does the tsquery have to use the same configuration?
> >> I wish I knew this myself. :-) Whatever I had done happened to work
> >> but that was largely through people on IRC wal
Bruce Momjian wrote:
> Ron Mayer wrote:
>> We need more feedback from users.
> Well, I am waiting for other hackers to get involved, but if they don't,
> I have to evaluate it myself on the email lists.
Personally, I think documentation changes would be an OK way to
to handle
Bruce Momjian wrote:
> Ron Mayer wrote:
>> I wish I knew this myself. :-) Whatever I had done happened to work
>> but that was largely through people on IRC walking me through it.
>
> This illustrates the major issue --- that this has to be simple for
> people to get started, while keeping the c
Ron Mayer wrote:
> We need more feedback from users.
> >>> Well, I am waiting for other hackers to get involved, but if they don't,
> >>> I have to evaluate it myself on the email lists.
> >> Personally, I think documentation changes would be an OK way to
> >> to handle it. Something that ma
Bruce Momjian wrote:
> Ron Mayer wrote:
>> Bruce Momjian wrote:
>>> Oleg Bartunov wrote:
What is a basis of your assumption ?
>> I think I asked about this kind of usage a couple years back;...
>>
>> http://archives.postgresql.org/pgsql-general/2005-10/msg00475.php
>> http://archives.postgres
Ron Mayer wrote:
> Bruce Momjian wrote:
> > Oleg Bartunov wrote:
> >> What is a basis of your assumption ? In my opinion, it's very limited
> >> use of text search, because it doesn't supports ranking. For 4-5 years
> >> of tsearch2 usage I never used it and I never seem in mailing lists.
> >> This
Oleg Bartunov wrote:
> On Tue, 31 Jul 2007, Bruce Momjian wrote:
>
> > Oleg Bartunov wrote:
> >> On Tue, 31 Jul 2007, Bruce Momjian wrote:
> >>
> > And if we have to require the configuration name in CREATE INDEX, it has
> > to be used in WHERE, so we might as well just remove the default
Bruce Momjian wrote:
> Oleg Bartunov wrote:
>> What is a basis of your assumption ? In my opinion, it's very limited
>> use of text search, because it doesn't supports ranking. For 4-5 years
>> of tsearch2 usage I never used it and I never seem in mailing lists.
>> This is very user-oriented featur
On Tue, 31 Jul 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
On Tue, 31 Jul 2007, Bruce Momjian wrote:
And if we have to require the configuration name in CREATE INDEX, it has
to be used in WHERE, so we might as well just remove the default
capability and always require the configuration na
Oleg Bartunov wrote:
> On Tue, 31 Jul 2007, Bruce Momjian wrote:
>
> >>> And if we have to require the configuration name in CREATE INDEX, it has
> >>> to be used in WHERE, so we might as well just remove the default
> >>> capability and always require the configuration name.
> >>
> >> this is ver
On Tue, 31 Jul 2007, Bruce Momjian wrote:
And if we have to require the configuration name in CREATE INDEX, it has
to be used in WHERE, so we might as well just remove the default
capability and always require the configuration name.
this is very rare use case for text searching
1. expression
Oleg Bartunov wrote:
> >> If we remove default_text_search_config, it would also make ::tsvector
> >> casting useless as well.
> >
> > OK, I just found a case that I think is going to make #3 a requirement
> > (remove default_text_search_config).
> >
> > How is a CREATE INDEX ... to_tsvector(col) g
On Mon, 30 Jul 2007, Bruce Momjian wrote:
Bruce Momjian wrote:
We have to decide if we want a GUC default_text_search_config, and if so
when can it be changed.
Right now there are three ways to create a tsvector (or tsquery)
::tsvector
to_tsvector(value)
to_tsvector(co
On Mon, 30 Jul 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
OK, here is what I am thinking. If we make default_text_search_config
super-user-only, then the user can't do SET (using "zero_damaged_pages"
as a superuser-only example):
test=> set zero_damaged_pages = on;
ERROR:
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
>
> > > 3) Remove default_text_search_config and require the
> > > configuration to be specified in each function call.
> > >
> > > If we remove default_text_search_config, it would also make ::tsvector
> > > casting use
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > 3) Remove default_text_search_config and require the
> >configuration to be specified in each function call.
> >
> > If we remove default_text_search_config, it would also make ::tsvector
> > casting useless as well.
>
> OK, I just foun
Bruce Momjian wrote:
> We have to decide if we want a GUC default_text_search_config, and if so
> when can it be changed.
>
> Right now there are three ways to create a tsvector (or tsquery)
>
> ::tsvector
> to_tsvector(value)
> to_tsvector(config, value)
>
> (ignoring plainto_
Oleg Bartunov wrote:
> > OK, here is what I am thinking. If we make default_text_search_config
> > super-user-only, then the user can't do SET (using "zero_damaged_pages"
> > as a superuser-only example):
> >
> > test=> set zero_damaged_pages = on;
> > ERROR: permission denied to set para
On Fri, 27 Jul 2007, Bruce Momjian wrote:
Magnus Hagander wrote:
However, the big problem is that the expressions used in expression
indexes should not change their output based on the value of a GUC
variable (because it would corrupt the index), but in the case above,
default_text_search_confi
Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> However, the big problem is that the expressions used in expression
>>> indexes should not change their output based on the value of a GUC
>>> variable (because it would corrupt the index), but in the case above,
>>> default_text_search_config contr
Magnus Hagander wrote:
> > However, the big problem is that the expressions used in expression
> > indexes should not change their output based on the value of a GUC
> > variable (because it would corrupt the index), but in the case above,
> > default_text_search_config controls what configuration
On Thu, Jul 26, 2007 at 06:23:51PM -0400, Bruce Momjian wrote:
> Oleg Bartunov wrote:
> > >> Second, I can't figure out how to reference a non-default
> > >> configuration.
> > >
> > > See the multi-argument versions of to_tsvector etc.
> > >
> > > I do see a problem with having to_tsvector(config,
> configuration has NOTHING with language ! This is a most frequent myth about
> configuration. It's just the way we chose for default_text_search_config to
> use language part of locale at initdb time.
> text search configuration is just a bind between parser to use for
> breaking document by lexe
On Fri, 27 Jul 2007, Pavel Stehule wrote:
2007/7/27, Oleg Bartunov <[EMAIL PROTECTED]>:
On Fri, 27 Jul 2007, Pavel Stehule wrote:
1) Document the problem and do nothing else.
2) Make default_text_search_config a postgresql.conf-only
setting, thereby making it impos
2007/7/27, Oleg Bartunov <[EMAIL PROTECTED]>:
> On Fri, 27 Jul 2007, Pavel Stehule wrote:
>
> >>
> >> 1) Document the problem and do nothing else.
> >> 2) Make default_text_search_config a postgresql.conf-only
> >>setting, thereby making it impossible to change by non-su
On Fri, 27 Jul 2007, Pavel Stehule wrote:
1) Document the problem and do nothing else.
2) Make default_text_search_config a postgresql.conf-only
setting, thereby making it impossible to change by non-super
users, or make it a super-user-only setting.
>
> 1) Document the problem and do nothing else.
> 2) Make default_text_search_config a postgresql.conf-only
>setting, thereby making it impossible to change by non-super
>users, or make it a super-user-only setting.
> 3) Remove default_text_search_co
Oleg Bartunov wrote:
> >> Second, I can't figure out how to reference a non-default
> >> configuration.
> >
> > See the multi-argument versions of to_tsvector etc.
> >
> > I do see a problem with having to_tsvector(config, text) plus
> > to_tsvector(text) where the latter implicitly references a co
54 matches
Mail list logo
