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 trigger arguments
be anything but a list of strings.
I'm
Marc G. Fournier wrote:
--On Thursday, August 16, 2007 23:16:09 +0200 Magnus Hagander
[EMAIL PROTECTED] wrote:
But my question still stands - how much work to stop-gap fix it on the
old one?
rsync should be upgraded now ...
Thanks!
Hopefully that should fix the short-term problem.
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
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.
--
Heikki
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
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
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 trigger
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 setting a
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 usually
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
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 a GUC
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
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
would be
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
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 enough.
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 efficiently?
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 never had
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
per-cell
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 list;
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
-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 stands - how much
-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 if we
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.
Certainly.
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
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 of at
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 change is
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
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
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,
-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 to document
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 their OS.
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 to
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 is all trace of
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
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
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 we are
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
-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 TSvector
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 smoke test
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 suggested this
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? It
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
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.
43 matches
Mail list logo
