Tom Lane [EMAIL PROTECTED] wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Uh, no. Function names for example are subject to search-path
confusion.
Wait, are they? They are in PL languages but only because most
languages store their source code as
On 8/17/07, Tom Lane [EMAIL PROTECTED] wrote:
At the moment I feel our thoughts have to revolve not around adding
complexity to tsearch, but taking stuff out. If we ship it with no
schema support for TS objects in 8.3, we can always add that later,
if there proves to be real demand for that
Digging through the simple vs advanced user discussion, I don't think
expression indexes are really the right idea. It seems a bit fragile,
you need a certain amount of knowledge about the optimizer to figure
out if your queries can even use the index, and it's just plain ugly.
It also seems like
Decibel! wrote:
The advantage to Bruce's idea is that it sounds pretty simple to
implement. While it wouldn't be of use for many general cases, it
*would* be useful for read-only tables, ie: old partitions.
Wouldn't the mostcommon case by foreign key checks against tables that
essentially
Hm, I suppose this kluge in gram.y for substr_list isn't necessary any
more? Don't really see a downside to leaving it, just thought I would mention
it since I noticed the comment is outdated.
| a_expr substr_for
{
/*
* Since there are no cases where this syntax
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 constructed with en_US is NOT the same as a vector
constructed with fr_FR and it's silly to
Trevor Talbot wrote:
Digging through the simple vs advanced user discussion, I don't think
expression indexes are really the right idea. It seems a bit fragile,
you need a certain amount of knowledge about the optimizer to figure
out if your queries can even use the index, and it's just plain
Gregory Stark [EMAIL PROTECTED] writes:
Hm, I suppose this kluge in gram.y for substr_list isn't necessary any
more?
It's still necessary, because if you write
select substring('1234' for '3');
you should get 123, but what you will get without the cast is 3
because the preferred match
On 8/18/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Remember an expression index can be a user-created function so you can
embed whatever you want in your function and just index it's output,
just like you would with a trigger creating a separate column.
Well, you could create a function that
Trevor Talbot [EMAIL PROTECTED] writes:
Currently you can schema-qualify objects where you need to, to avoid
issues with search_path subversion. If it's impossible to
schema-qualify tsearch configs now, when schema support is later added
it suddenly exposes everyone to risks that didn't exist
Oleg Bartunov [EMAIL PROTECTED] writes:
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'm working from the 0.58 version --- that was the latest last I looked.
There are still
Trevor Talbot wrote:
On 8/18/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Remember an expression index can be a user-created function so you can
embed whatever you want in your function and just index it's output,
just like you would with a trigger creating a separate column.
Well, you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
Trevor Talbot wrote:
On 8/18/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Remember an expression index can be a user-created function so you can
embed whatever you want in your function and just index it's output,
just like
On 8/18/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Trevor Talbot wrote:
Well, you could create a function that returns a tsvector, but how do
you get that to work with queries? I've been under the impression the
expressions need to match (in the normal case, be the same function
with
On 8/18/07, Tom Lane [EMAIL PROTECTED] wrote:
As my copy of the patch currently stands, there are two built-in trigger
functions, tsvector_update_trigger and tsvector_update_trigger_column.
The first expects trigger arguments
name of tsvector col, name of tsconfig to use, name(s) of text
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
Trevor Talbot wrote:
On 8/18/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Remember an expression index can be a user-created function so you can
embed whatever you want in your function and just
Trevor Talbot wrote:
On 8/18/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Trevor Talbot wrote:
Well, you could create a function that returns a tsvector, but how do
you get that to work with queries? I've been under the impression the
expressions need to match (in the normal case, be
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
On 8/15/07, Tom Lane [EMAIL PROTECTED] wrote:
For example, log_line_prefix is misnamed under this rule, and ought to
be logging_line_prefix. Similarly, redirect_stderr would become
logging_something --- I'd prefer
On Aug 18, 2007, at 20:44 , Andrew Dunstan wrote:
Logging_collector won the day. I have just committed CSVlogs with
that change.
Congrats!
A couple last-minute correx:
http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/
func.sgml?r1=1.385r2=1.386
s/log collector if
Michael Glaesemann wrote:
On Aug 18, 2007, at 20:44 , Andrew Dunstan wrote:
Logging_collector won the day. I have just committed CSVlogs with
that change.
Congrats!
A couple last-minute correx:
thanks. fixed.
cheers
andrew
---(end of
hello,
I'm working on an application that once in a while needs to shuffle some data
around with a query like:
INSERT INTO foo (some_field, bar_FK, baz_FK)
SELECT some_field,
12345 AS bar_FK,
baz_FK
FROM foo
WHERE bar_FK=123
ie. copy a block of data from a table into
21 matches
Mail list logo
