Re: [HACKERS] Proposed Query Planner TODO items

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

[HACKERS] dblink - custom datatypes NOW work :)

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

Re: [HACKERS] [PATCHES] log session end - again

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

Re: [HACKERS] Transaction aborts on syntax error.

> 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

Re: [HACKERS] [PATCHES] log session end - again

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

Re: [HACKERS] Proposed Query Planner TODO items

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

Re: [HACKERS] Transaction aborts on syntax error.

"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

Re: [HACKERS] Transaction aborts on syntax error.

> > 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

[HACKERS] pg_restore problems and suggested resolution

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

Re: [HACKERS] Transaction aborts on syntax error.

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

Re: [HACKERS] Transaction aborts on syntax error.

"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

Re: [HACKERS] pg_restore problems and suggested resolution

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

Re: [HACKERS] pg_restore problems and suggested resolution

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

Re: [HACKERS] Proposed Query Planner TODO items

[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

Re: [HACKERS] Transaction aborts on syntax error.

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

Re: [HACKERS] pg_restore problems and suggested resolution

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,

Re: [HACKERS] pg_restore problems and suggested resolution

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.