Re: [BUGS] BUG #3847: plpython trigger caches table structure - doesn't see new / changed columns
Works perfectly on my test case. Thanks! On Jan 1, 2008 8:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Mark Reid" <[EMAIL PROTECTED]> writes: > > The trigger function does not recognize the "test4" column the second > time > > it is added - the update throws an error. > > Try this patch: > http://archives.postgresql.org/pgsql-committers/2008-01/msg00016.php > >regards, tom lane >
Re: [BUGS] BUG #3847: plpython trigger caches table structure - doesn't see new / changed columns
We've run our real-life test cases and they've all worked properly using this patch too. Thanks again. -Mark. On Jan 1, 2008 8:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Mark Reid" <[EMAIL PROTECTED]> writes: > > The trigger function does not recognize the "test4" column the second > time > > it is added - the update throws an error. > > Try this patch: > http://archives.postgresql.org/pgsql-committers/2008-01/msg00016.php > >regards, tom lane >
Re: [BUGS] BUG #3822: Nonstandard precedence for comparison operators
Pedro Gimeno wrote: > > The spec seems to barely have a notion of operator precedence at all --- > > The precedence is given by the parse tree and is well defined. Perhaps > it may vary for a given operator depending on the context but it's > clearly different to the one PostgreSQL is using in the examples I gave. It would be interesting if someone could work out an operator precedence table that the spec would require, so we can contrast that with the one we currently implement. At the moment I couldn't really tell how extensive the problem is. Even if we change nothing, this would be useful for documentation. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
