On Sunday 01 November 2009 16:19:43 Andres Freund wrote:
> While playing around/evaluating tsearch I notices that to_tsvector is
> obscenely slow for some files. After some profiling I found that this is
> due using a seperate TSParser in p_ishost/p_isURLPath in wparser_def.c. If
> a multibyte en
On Sun, Nov 08, 2009 at 05:00:53PM +0100, Andres Freund wrote:
> On Sunday 01 November 2009 16:19:43 Andres Freund wrote:
> > While playing around/evaluating tsearch I notices that to_tsvector is
> > obscenely slow for some files. After some profiling I found that this is
> > due using a seperate
Tom,
> BTW, this brings up another point, which is that up to now it's often
> been possible to use plpgsql variable names that conflict with
> core-parser reserved words, so long as you didn't need to use the
> reserved word with its special meaning. That will stop working when
> this patch goes
On Thu, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
> This is useful in conjunction with PL/Proxy and similar RPC-type
> setups. On the frontend/proxy instances you only create the type, and
> the backend instances you create the storage for the type, and the
> database system would give yo
On Sun, 2009-11-08 at 13:41 -0800, Jeff Davis wrote:
> On Sat, 2009-11-07 at 10:56 -0800, Jeff Davis wrote:
> > EXCLUDE probably flows most nicely with the optional USING clause or
> > without. My only complaint was that it's a transitive verb, so it seems
> > to impart more meaning than it actuall
On Sunday 08 November 2009 17:41:15 Kenneth Marshall wrote:
> On Sun, Nov 08, 2009 at 05:00:53PM +0100, Andres Freund wrote:
> > As nobody commented here is a corrected (stupid thinko) and cleaned up
> > version. Anyone cares to comment whether I am the only one thinking this
> > is an issue?
> > A
Tom Lane wrote:
> "David E. Wheeler" writes:
> > That works.
>
> >plpgsql_variable_conflict = fatal | variable-first | column-first
>
> If we do that, presumably the per-function syntax would be
>
> #variable_conflict variable_first
>
> and so on, which is clear enough but might be t
Alvaro Herrera writes:
> If there's some way to "paste" it automatically (like, say, an
> appropriate UPDATE incantation on pg_proc) then that doesn't seem like
> an important problem.
True, you could do UPDATE pg_proc SET prosrc = 'foo' || prosrc
WHERE something-appropriate.
On Fri, Nov 06, 2009 at 07:09:46PM -0800, David E. Wheeler wrote:
> On Nov 6, 2009, at 6:57 PM, Tom Lane wrote:
> >If we do that, presumably the per-function syntax would be
> > #variable_conflict variable_first
> >and so on, which is clear enough but might be thought a bit verbose
> >for somet
The next CommitFest is scheduled to start in a week. So far, it
doesn't look too bad, though a lot could change between now and then.
I would personally prefer not to be involved in the management of the
next CommitFest. Having done all of the July CommitFest and a good
chunk of the September Co
Robert Haas writes:
> I would personally prefer not to be involved in the management of the
> next CommitFest. Having done all of the July CommitFest and a good
> chunk of the September CommitFest, I am feeling a bit burned out.
You did yeoman work on both --- thanks for that!
Do we have anothe
> > This is useful in conjunction with PL/Proxy and similar RPC-type
> > setups. On the frontend/proxy instances you only create the type, and
> > the backend instances you create the storage for the type, and the
> > database system would give you a little support keeping them in sync.
> > Think i
On Sun, 2009-11-08 at 22:03 +, Simon Riggs wrote:
> Don't think that name is very useful either... sounds like you want to
> exclude operators, which is why I got lost in the first place. I'd call
> them "generic exclusion constraints" or "user-defined exclusion
> constraints". Sorry for this.
13 matches
Mail list logo
