On Sat, 18 Aug 2007, Mike Rylander wrote:
On 8/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Aug 17, 2007 at 04:06:15PM -0700, Josh Berkus wrote:
Bruce,
Oh, so you want the config inside each tsvector value. Interesting
idea.
Yea
Tom and Bruce, what version of patch you're using ?
Bruce complained about using OID in arguments of functions, but
AFAIR, it was removed in 0.58 version of patch.
I and Teodor are very busy and just can't follow all discussions, so
we have to rely on people's wisdom. If we have so many problem
On Sat, 18 Aug 2007, [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Aug 17, 2007 at 04:06:15PM -0700, Josh Berkus wrote:
> Bruce,
>
> > Oh, so you want the config inside each tsvector value. б═Interesting
> > idea.
>
> Yeah, hasn't anyone suggested this before
On 8/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, Aug 17, 2007 at 04:06:15PM -0700, Josh Berkus wrote:
> > Bruce,
> >
> > > Oh, so you want the config inside each tsvector value. Interesting
> > > idea.
> >
> > Yeah, hasn't anyone
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> I switched the code over to the sysv_sema style api. It's gotten a bit grotty
>> and I would clean it up if it weren't a temporary test program. If we find a
>> real problem perhaps I should add a test case like this to the "
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Aug 17, 2007 at 04:06:15PM -0700, Josh Berkus wrote:
> Bruce,
>
> > Oh, so you want the config inside each tsvector value. Interesting
> > idea.
>
> Yeah, hasn't anyone suggested this before? It seems like the obvious
> solution. A TSvect
On 8/18/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> The main drawback to the V1-call-convention function call mechanism,
> compared to ordinary C functions, is that you can't instantly see what
> the function arguments are supposed to be. I think that good coding
> style demands ameliorating this by
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Oh, so you want the config inside each tsvector value. Interesting
>> idea.
> Yeah, hasn't anyone suggested this before? It seems like the obvious
> solution.
It might be an obvious solution, but to some other problem than the one
we have. The problem
Tom,
> It might be an obvious solution, but to some other problem than the one
> we have. The problem we are trying to address is how to know which
> config to use to construct a *new* tsvector.
Oh, right. Back to the circular arguments then ...
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Fra
Bruce,
> Oh, so you want the config inside each tsvector value. Interesting
> idea.
Yeah, hasn't anyone suggested this before? It seems like the obvious
solution. A TSvector constructed with en_US is NOT the same as a vector
constructed with fr_FR and it's silly to pretend that they are comp
Joshua D. Drake wrote:
> Tom Lane wrote:
>> Robert Treat <[EMAIL PROTECTED]> writes:
>>> What exactly does default_text_search_config buy us? I think it is
>>> supposed
>>> to simplify things, but it sounds like it adds a bunch of corner cases,
>> Well, the main thing we'd lose if we remove it
Gregory Stark wrote:
>
> I'm having trouble following what's going on with autovacuum and I'm finding
> the existing logging insufficient. In particular that it's only logging vacuum
> runs *after* the vacuum finishes makes it hard to see what vacuums are running
> at any given time. Also, I want
Gregory Stark wrote:
> I switched the code over to the sysv_sema style api. It's gotten a bit grotty
> and I would clean it up if it weren't a temporary test program. If we find a
> real problem perhaps I should add a test case like this to the "smoke test" in
> ipc_test.c so people can check thei
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Page wrote:
> Marc G. Fournier wrote:
>>> I'll try to take a look at the other one as soon as I can, hopefully
>>> this weekend - if you have the docs by then.
>>
>> If you need information, just ask for it ...
>
> Magnus has repeatedly asked you
I don't want to pick on Teodor in particular, because I've seen other
people do this too, but which of these functions do you find more
readable?
Datum
to_tsquery_byname(PG_FUNCTION_ARGS)
{
PG_RETURN_DATUM(DirectFunctionCall2(
to_tsquery_byid,
On 8/17/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> Attached are some new functions that extend the libpq api to make
after sending the mail, we noticed some dead code that might be
confusing...in PQparamClear there was some legacy code referring to
'slab' which has no effect...ignore. Also s
Marc G. Fournier wrote:
I'll try to take a look at the other one as soon as I can, hopefully
this weekend - if you have the docs by then.
If you need information, just ask for it ...
Magnus has repeatedly asked you to document it on PMT as we have been
doing as a matter of course for everyth
Attached are some new functions that extend the libpq api to make
calling the parameterized interfaces easier, especially when making
binary calls. IMO, this fills one of the two big missing parts of the
libpq api when making binary database calls, the other being client
side handling of complex s
Tom Lane wrote:
> A couple months ago I wrote:
> > Lastly, I'm unhappy that the patch still keeps a lot of configuration
> > information, such as stop word lists, in the filesystem rather than the
> > database. It seems to me that the single easiest and most useful part
> > of a configuration to c
Josh Berkus wrote:
> Folks,
>
> Here's something not to forget in this whole business: the present TSearch2
> implementation permits you to have a different tsvector configuration for
> each *row*, not just each column. That is, applications can be built with
> "per-cell" configs.
>
> I know
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Friday, August 17, 2007 08:40:11 +0200 Magnus Hagander
<[EMAIL PROTECTED]> wrote:
> Marc G. Fournier wrote:
>>
>>
>> --On Thursday, August 16, 2007 23:16:09 +0200 Magnus Hagander
>> <[EMAIL PROTECTED]> wrote:
>>
>>> But my question still sta
Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Here's something not to forget in this whole business: the present TSearch2
> > implementation permits you to have a different tsvector configuration for
> > each *row*, not just each column. That is, applications can be built with
> >
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, the main thing we'd lose if we remove it is all trace of upward
>> compatibility from the contrib version of tsearch.
> I don't think this is all that big of a deal. In fact I would expect it
> going from contrib to core and
Josh Berkus <[EMAIL PROTECTED]> writes:
> Here's something not to forget in this whole business: the present TSearch2
> implementation permits you to have a different tsvector configuration for
> each *row*, not just each column. That is, applications can be built with
> "per-cell" configs.
Cert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>> What exactly does default_text_search_config buy us? I think it is supposed
>> to simplify things, but it sounds like it adds a bunch of corner cases,
>
> Well, the main thing we'd lose
A couple months ago I wrote:
> Lastly, I'm unhappy that the patch still keeps a lot of configuration
> information, such as stop word lists, in the filesystem rather than the
> database. It seems to me that the single easiest and most useful part
> of a configuration to change is the stop word lis
Folks,
Here's something not to forget in this whole business: the present TSearch2
implementation permits you to have a different tsvector configuration for
each *row*, not just each column. That is, applications can be built with
"per-cell" configs.
I know of at least one out there: Ubuntu's
Luke Lonergan wrote:
> All - we have customers who very much want tsearch2 and will benefit from its
> inclusion in core.
>
> We are also struggling with the update trigger approach for various reasons.
>
> Is there a good alternative? Can we embed tsvector updates into the core
> code efficie
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Fri, Aug 17, 2007 at 10:42:09AM -0400, Tom Lane wrote:
>> If you insist on a solution that involves attaching type information
>> to trigger arguments, then we can forget about getting tsearch into 8.3.
> Hmm, maybe I didn't explain clearly e
All - we have customers who very much want tsearch2 and will benefit from its
inclusion in core.
We are also struggling with the update trigger approach for various reasons.
Is there a good alternative? Can we embed tsvector updates into the core code
efficiently?
- Luke
Msg is shrt cuz m on
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 17. August 2007 05:15 schrieb Tom Lane:
>> Actually ... I'm suddenly not happy about the choice to put text search
>> configurations etc. into schemas at all.
> But that isn't different from any other part of the system. A proper fix
> w
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Thu, 16 Aug 2007, Josh Berkus wrote:
>> First off, I'll assert that backup/restore is a serious issue and while the
>> folks who want Tsearch in core now are dismissing it, we'll be fielding the
>> complaints later. Any solution which involves setting
Robert Treat <[EMAIL PROTECTED]> writes:
> What exactly does default_text_search_config buy us? I think it is supposed
> to simplify things, but it sounds like it adds a bunch of corner cases,
Well, the main thing we'd lose if we remove it is all trace of upward
compatibility from the contrib v
On Fri, Aug 17, 2007 at 10:42:09AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > I'm unsure how it works now, but it seems reasonable that when a
> > regclass/regtype/regetc is passed to a trigger, pass it in OID form.
>
> If you insist on a solution that involves
Robert Treat wrote:
> > The only remaining problem I see is that the rest of the documentation
> > relies heavily on default_text_search_config when in fact the most
> > common usage with tables and indexes can't use it. tsquery can use the
> > default easily, but I am betting that tsvector usuall
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Fri, Aug 17, 2007 at 01:16:22AM -0400, Tom Lane wrote:
>> That seems like it'd fix the problem for expression indexes on
>> to_tsvector calls, but I don't see how it fixes the problem for
>> triggers. We don't have any clear path for making t
On Thursday 16 August 2007 15:58, Bruce Momjian wrote:
> Josh Berkus wrote:
> > All,
> >
> > First off, I'll assert that backup/restore is a serious issue and while
> > the folks who want Tsearch in core now are dismissing it, we'll be
> > fielding the complaints later. Any solution which involves
I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
sometimes just times out and there is no way to make it wait a little longer.
I would like to add an option to be able to change that, say
pg_ctl -w --timeout=120. Comments?
--
Peter Eisentraut
http://developer.postgr
Bruce Momjian wrote:
I would be happy if all text search functions began with 'ts', 'ts_', or
'to_ts', and if we don't clean this up now, it is going to be harder in
the future.
+1 from me. \df is also much more useful then.
> I think users can expect some migration for text search in
8.3 as
Bruce Momjian wrote:
> These patches will be held for 8.4:
>
> o Grouped Index Tuples (GIT)
> o Bitmap scan changes
> o Stream bitmaps (API change for Group Index Tuples)
> o Maintaining cluster order on insert
>
> I believe Heikki is in agreement on this.
Yes.
--
Am Freitag, 17. August 2007 05:15 schrieb Tom Lane:
> Actually ... I'm suddenly not happy about the choice to put text search
> configurations etc. into schemas at all. We've been sitting here and
> assuming that to_tsvector('english', my_text_col) has a well defined
> meaning --- but as the patch
41 matches
Mail list logo
