Christopher Kings-Lynne wrote:
As an implementation issue, I wonder why these things are hacking
permanent on-disk data structures anyway, when what is wanted is only a
temporary suspension of triggers/rules within a single backend. Some
kind of superuser-only SET variable might be a better idea.
As an implementation issue, I wonder why these things are hacking
permanent on-disk data structures anyway, when what is wanted is only a
temporary suspension of triggers/rules within a single backend. Some
kind of superuser-only SET variable might be a better idea. It'd not be
hard to implement,
Josh Berkus wrote:
> Bruce,
>
> > > So, whatever "error handling mode" conveniences we wish to put in should
> > > be put in on the client side.
> >
> > Added to TODO:
> >
> > * Use nested transactions to prevent syntax errors from aborting
> > ?a transaction
>
> Hmmm I'm
[EMAIL PROTECTED] writes:
> http://developer.osdl.org/markw/dbt3-pgsql/66/
> There's a run with a modified Q21. Made a huge improvement in Q21.
Okay, looks like we know what we need to attack to solve Q21... actually
solving it will be a tad harder ;-) but we understand where the problem is.
I
Joseph Tate <[EMAIL PROTECTED]> writes:
> So now that I've looked at the code, I think that this solution is a
> little too simplistic unfortunately. Now I'm leaning towards
> --diable-rules. Am I correct in thinking that if I change
> pg_class.relhasrules to 'f' that the rules will not be pro
Joseph Tate wrote:
I propose pg_restore --disable-triggers be modified so that triggers are
disabled on the tables that OID fixing is going to UPDATE. I'll
hopefully have a patch against REL7_4_STABLE for this soon, but I
haven't started it yet. Does anyone have any suggestions? Has someone
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> which might not be for every statement. Savepoints that you don't
>> actually need are going to be a fairly expensive overhead, AFAICS.
> Well with other db's per statement rollback is a no overhead feature,
> so this is pg specific.
I
Bruce,
> > So, whatever "error handling mode" conveniences we wish to put in should
> > be put in on the client side.
>
> Added to TODO:
>
> * Use nested transactions to prevent syntax errors from aborting
> a transaction
Hmmm I'm not sure how you arrived at this wording
I've got a custom (-Fc) pg_dump output from a fairly complex 7.2.x db
schema. It has such things as user defined functions, OIDs, rules and
triggers, etc. When I try to restore it to a 7.4 database, it fails
because of some differences in the CREATE TABLE commands (I've got a
column of type T
> > It seems to me, that leaving all this to the client (which implicitly
> > inserts savepoints) can never be as efficient as a serverside feature.
>
> I think this is an overly narrow view of "efficiency". With client
> control, the client can insert savepoints whereever it needs them,
Yes, b
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> It seems to me, that leaving all this to the client (which implicitly
> inserts savepoints) can never be as efficient as a serverside feature.
I think this is an overly narrow view of "efficiency". With client
control, the client can inser
Dennis Haney <[EMAIL PROTECTED]> writes:
> You are refering to:
> @inproceedings{ hellerstein93predicate,
> author = "Joseph M. Hellerstein and Michael Stonebraker",
> title = "Predicate migration: optimizing queries with expensive
> predicates",
Yup, I sure am. This is the same thesis r
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Andrew Dunstan wrote:
>
> You can find i
> In both cases, the transaction either commits or rollback occurs. No
> other option is possible at the end of the transaction, but in the first
> style of transaction semantics you get a "mid-way" decision point. This
> only refers to retryable errors, since errors like access rights
> violation
You can find it here.
http://archives.postgresql.org/pgsql-patches/2004-02/msg00072.php
I know Neil was reviewing it and had a minor doc style quibble, as well
as the question he raised on -hackers about psql tab completion.
cheers
andrew
Bruce Momjian wrote:
Andrew Dunstan wrote:
Based o
Mark Gibson wrote:
I've found that dblink works without the oid map, ie: dblink(... , ...
, false)
but returns the error when enabled, ie: dblink(... , ... , true)
Hello,
I've found the problem, although I'm still a bit confused by it.
When the call to SPI_finish() at the end of pgresultGetTu
You are refering to:
@inproceedings{ hellerstein93predicate,
author = "Joseph M. Hellerstein and Michael Stonebraker",
title = "Predicate migration: optimizing queries with expensive
predicates",
pages = "267--276",
year = "1993",
abstract = "The traditional focus of relational que
17 matches
Mail list logo
