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 it
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 broadcast)--
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.385&r2=1.386
s/log collector if running/l
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 "lo
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 no
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 yo
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
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
>
-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,
>
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.
>
>
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 s
"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'
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 t
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 pref
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 pl
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
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 a
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 map
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
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
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 the
21 matches
Mail list logo
