Michael Fuhr <[EMAIL PROTECTED]> writes:
> I've found a situation that causes DROP FUNCTION to fail (tested
> in 8.1.6, 8.2.1, and 8.3devel):
Ugh ... I haven't traced this through in detail, but I'm pretty sure
the problem arises from the fact that dependency.c traces through
auto/internal depende
I've found a situation that causes DROP FUNCTION to fail (tested
in 8.1.6, 8.2.1, and 8.3devel):
CREATE TABLE foo (id integer);
CREATE FUNCTION foofunc() RETURNS trigger AS $$
BEGIN
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Then in concurrent sessions:
A: BEGIN;
A: CREATE TRIGGER footrig BEFOR
I complained about how:
> The query is
> SELECT p1.opcname, p1.opcfamily
> FROM pg_opclass AS p1
> WHERE NOT EXISTS(SELECT 1 FROM pg_amop AS p2
> WHERE p2.amopfamily = p1.opcfamily
>AND binary_coercible(p1.opcintype, p2.amoplefttype));
> and investigation show
On Sun, Jan 21, 2007 at 11:39:45AM +, Heikki Linnakangas wrote:
> Russell Smith wrote:
> >Strange idea that I haven't researched, Given Vacuum can't be run in a
> >transaction, it is possible at a certain point to quit the current
> >transaction and start another one. There has been much ch
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> At a minimum we need to stop forcing a rollback just because we have a
> syntax error. It makes development a complete pain in the butt and is
> one of the most, "WTF" looks I get when I am training.
> postgres=# begin;
> BEGIN
> postgres=# create ta
> I'd like to see a TODO item to allow an *option* to be set to choose
> between these two transactional behaviours.
> - abort on error
> - continue on error i.e. COMMIT can/might succeed - though there are
> still cases where it cannot, such as a serializable exception.
>
> That's a major change
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> - continue on error i.e. COMMIT can/might succeed - though there are
>> still cases where it cannot, such as a serializable exception.
> and what should be the behaviour of that? the same as rollba
Martijn van Oosterhout writes:
> You have operators like "contains" and "is contained by" which would be
> opposites of eachother, but could never be used in a b-tree class.
A quick count shows that 46% of the entries in pg_operator that have an
oprcom link are not in any btree opclass. For oprn
On 1/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Fri, 2007-01-19 at 15:12 -0500, Merlin Moncure wrote:
> The missing piece of the puzzle is the ability to recover a failed
> transaction without issuing a full commit/rollback.
Agreed.
I'd like to see a TODO item to allow an *option* to be
On Sun, 2007-01-21 at 08:36 +0100, Peter Eisentraut wrote:
> Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Neil Conway wrote:
> > >> The regression.diffs are attached. Note that this reproduces
> > >> consistently, but only occurs if I use the "runtest" Makefile
> > >> targ
On Fri, 2007-01-19 at 15:12 -0500, Merlin Moncure wrote:
> The missing piece of the puzzle is the ability to recover a failed
> transaction without issuing a full commit/rollback.
Agreed.
AFAIK all other RDBMS interpret the SQL Standard to mean that a
statement can fail with an ERROR, then furt
On Sun, Jan 21, 2007 at 12:24:38PM +, Simon Riggs wrote:
> Partial vacuum would still be possible if you remembered where you got
> to in the VACUUM and then started from that same point next time. It
> could then go to the end of the table and wrap back around.
ISTM the Dead Space Map would g
On Sat, 2007-01-20 at 09:41 +1100, Russell Smith wrote:
> Darcy Buskermolen wrote:
> > [snip]
> >
> > Another thought, is it at all possible to do a partial vacuum? ie spend
> > the
> > next 30 minutes vacuuming foo table, and update the fsm with what hew have
> > learned over the 30 mins, e
Russell Smith wrote:
Strange idea that I haven't researched, Given Vacuum can't be run in a
transaction, it is possible at a certain point to quit the current
transaction and start another one. There has been much chat and now a
TODO item about allowing multiple vacuums to not starve small ta
On Sun, Jan 21, 2007 at 09:39:32AM +, Gregory Stark wrote:
> I guess it's tricky since there may be operators which have valid negators and
> commutators but which don't get used by any btree operator class. Does
> Postgres actually make use of the oprcom and oprnegate in that case? Could
> the
"Tom Lane" <[EMAIL PROTECTED]> writes:
> So I'm thinking that the pg_am columns amorderstrategy and amdescorder are
> redundant and should be replaced with a simple boolean, "amcansort" perhaps.
> Any objections?
Any chance of getting rid of the remaining inter-operator relationship columns
in p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... However, I tried reverting the
>> change and things still did not work. The reason is that the test
>> programs are built with relative paths to libpq that look like
>> ../../../../../src/interfaces/libpq/libpq.sl.5
> This is
Tom Lane wrote:
> AFAICT, every buildfarm machine that runs ecpg tests has been failing
> since Peter's patch here:
> http://archives.postgresql.org/pgsql-committers/2007-01/msg00241.php
>
> Now it looks to me like Peter was simply wrong: we do need to include
> libpq because libecpg depends on it.
Sounds like good reason to get it in early... :)
It would be nice if there were some tests for this/that used this...
wasn't there a patch for that floating around somewhere?
On Sat, Jan 20, 2007 at 05:11:25PM -0500, Bruce Momjian wrote:
>
> What are people's opinions on this patch? (It is at t
19 matches
Mail list logo
