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
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 in.
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 you a
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 actually can.
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?
Andres
Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
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 something
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
Robert Haas robertmh...@gmail.com 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!
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 interface
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.
Either
13 matches
Mail list logo
