On Fri, 20 Nov 2009, Magnus Hagander wrote:
I've cleaned up the git repo, and re-enabled the mirror script. From
what I can tell it works fine. In theory you will need to use force
mode if you pulled the broken commit that was removed (the one with
the wrong message), but it seems this is not
On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote:
Is there any precedent for the sort of behavior that you are
implementing, that is, automatic sharing of variables between
independent executions of the same source container?
import foo
# bar is a regular, def'd function.
foo.bar()
...
On fre, 2009-11-20 at 01:20 -0700, James Pye wrote:
On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote:
Is there any precedent for the sort of behavior that you are
implementing, that is, automatic sharing of variables between
independent executions of the same source container?
import
On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote:
2009/11/20 Peter Eisentraut pete...@gmx.net:
On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote:
Is there any actual reason why we are building without thread safety
by default on most platforms?
Consistent defaults on all
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Note that we don't preserve notifications when the database restarts.
But 2PC can cope with restarts. How would that fit together?
The notifications are written to the state file at prepare. They can
On Nov 20, 2009, at 1:26 AM, Peter Eisentraut wrote:
because this is the same execution
Hrm, not necessarily. foo could be imported by another, completely independent
part of the program. foo is cached in sys.modules. bar() is executed and it's
still the same globals(). shared.
--
Sent via
Joachim Wieland wrote:
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Note that we don't preserve notifications when the database restarts.
But 2PC can cope with restarts. How would that fit together?
The notifications are written to the state
Am 19.11.2009 18:01, schrieb James Pye:
On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote:
The other approach, which is what James Pye's
new implementation proposes (as I understand it), is to convert
PostgreSQL types into specially made Python objects, such as
Postgres.types.record or
Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 11:04 PM, Joachim Wieland j...@mcknight.de wrote:
Given your example, what I am proposing now is to stop reading from
the queue once we see a not-yet-committed notification but once the
queue is full, read the uncommitted notifications,
Peter Eisentraut wrote:
I don't have a good overview over how many platforms would be affected
The anniversary of this thread is a few days early:
http://archives.postgresql.org/message-id/492ea404.5080...@esilo.com
--
Greg Smith2ndQuadrant Baltimore, MD
PostgreSQL Training,
On Thu, Nov 19, 2009 at 05:04:22PM -0700, Joshua Tolley wrote:
The body of the function is ordinary Perl code. In fact, the PL/Perl
!glue code wraps it inside a Perl subroutine. Anonymous code blocks cannot
!return a value; PL/Perl functions created with CREATE FUNCTION must
Peter Eisentraut wrote:
Let me be more verbose: I would assume that we want the configure
defaults to be the same on all platforms. We fail by default, for
example, if zlib and readline are not there, but you can turn them off
explicitly. If we turn thread-safety on by default, we
On Nov 20, 2009, at 2:04 AM, Joshua Tolley wrote:
On Wed, Nov 18, 2009 at 12:38:00PM +0200, Alexey Klyukin wrote:
Yes, current_call_data can't be allocate in the SPI memory context, since
it's used to extract the result after SPI_finish is called, although it
doesn't lead to problems here
On Nov 20, 2009, at 3:50 PM, Tim Bunce wrote:
When does the reference held by desc.reference get freed?
At the moment it looks like this would leak memory for each DO.
Isn't it also the case with the existing plperl code ? I've noticed that
free(prodesc) is called when it's no longer used
Tom Lane wrote:
Kenneth Marshall k...@rice.edu writes:
Without an order by, the order is not defined.
Yeah, but with the same data and the same software it should generally
give the same result; as evidenced by the fact that these same
regression tests have worked for most people for
On Fri, Nov 20, 2009 at 7:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
On Fri, 2009-11-20 at 06:47 +, Greg Stark wrote:
I missed the original discussion of this problem, do you happen to
remember the subject or url for the details?
December
On Fri, Nov 20, 2009 at 2:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner mar...@bluegap.ch wrote:
Hi,
Robert Haas wrote:
Settling on a syntax, and an internal representation for that
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote:
Hi
It seems that pl/pgsql ignores the DEFAULT value of domains for local
variables. With the following definitions in place
create domain myint as int default 0;
create or replace function myint() returns myint as $body$
In testing the TRIGGER WHEN patch, I notice that pg_dump is relying on
pg_get_triggerdef(triggeroid, true) (ie, pretty mode) to dump
triggers. This means that trigger WHEN conditions will be dumped
without adequate parenthesization to ensure they are interpreted the
same way when loaded into
On Thu, Nov 19, 2009 at 05:15:05PM -0700, u235sentinel wrote:
Does anyone have a link for pl/ruby? I found a link under the postgres
documentation and found a web site from there talking about the code.
However when I clicked on the link to download it I noticed ftp wouldn't
respond on
On Sun, 2009-11-15 at 17:17 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
So I'm in favor of committing part of the HS code even if there are
known failure conditions, as long as those conditions are well-defined.
If we're thinking of committing something that is known
On Fri, 2009-11-20 at 16:40 +0900, Josh Berkus wrote:
Yes. I'm realizing that because of the highly techincal nature of the
discussion and the language used few people other than you and Heikki
are aware of the major issues which still need work. It would be
helpful if someone could post a
Robert Haas wrote:
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote:
I've tried to create a patch, but didn't see how I'd convert the result
from get_typedefault() (A Node*, presumeably the parsetree corresponding
to the default expression?) into a plan that I could store
On Fri, Nov 20, 2009 at 12:51 PM, Florian G. Pflug f...@phlo.org wrote:
Robert Haas wrote:
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug f...@phlo.org wrote:
I've tried to create a patch, but didn't see how I'd convert the result
from get_typedefault() (A Node*, presumeably the parsetree
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
(1) change pg_dump to not prettify trigger definitions at all, or
(2) change pg_get_triggerdef from the submitted patch so that it
doesn't reduce parenthesization even in pretty mode.
Or somebody could bite the bullet and decouple
Tom Lane wrote:
In testing the TRIGGER WHEN patch, I notice that pg_dump is relying on
pg_get_triggerdef(triggeroid, true) (ie, pretty mode) to dump
triggers. This means that trigger WHEN conditions will be dumped
without adequate parenthesization to ensure they are interpreted the
same way
Greg Stark wrote:
From discussions in the bar it sounds like this was actually a false
start however as the RecentGlobalXmin in the backend doing the split
could be less aggressive than the RecentGlobalXmin used by some other
backend to hit the hint bits leading to inconsistent results :(
Kris Jurka wrote:
On Fri, 20 Nov 2009, Magnus Hagander wrote:
I've cleaned up the git repo, and re-enabled the mirror script. From
what I can tell it works fine. In theory you will need to use force
mode if you pulled the broken commit that was removed (the one with
the wrong message), but
On Fri, Nov 20, 2009 at 2:44 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Kris Jurka wrote:
On Fri, 20 Nov 2009, Magnus Hagander wrote:
I've cleaned up the git repo, and re-enabled the mirror script. From
what I can tell it works fine. In theory you will need to use force
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
[ TRIGGER WHEN patch ]
Applied with assorted revisions. AFAICT the system column issue is only
a problem for NEW references in BEFORE triggers --- those columns do
read correctly in OLD, and all the time in AFTER triggers. I revised
the
Andreas Pflug pgad...@pse-consulting.de writes:
Tom Lane wrote:
The easy ways out of this are
(1) change pg_dump to not prettify trigger definitions at all, or
(2) change pg_get_triggerdef from the submitted patch so that it
doesn't reduce parenthesization even in pretty mode.
The pretty
Jan Wieck janwi...@yahoo.com writes:
On 11/20/2009 1:12 AM, Tom Lane wrote:
Jan Wieck janwi...@yahoo.com writes:
But this brings up another point about the recent discussion of what
RENAME is good for. Removing RENAME may conflict with using OLD/NEW in
UPDATE ... RETURNING. No?
Um ...
On Fri, Nov 20, 2009 at 3:38 PM, Tom Lane t...@postgresql.org wrote:
Log Message:
---
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be
checked to determine whether the trigger should be fired.
For BEFORE triggers this is mostly a matter of spec compliance; but
Robert Haas robertmh...@gmail.com writes:
Random thought: would it be possible to use something like this to
optimize foreign key constraints, by not firing them if none of the
relevant columns have been updated?
There already is code in there to do that; see RI_FKey_keyequal_upd_fk
and
On Fri, Nov 20, 2009 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Random thought: would it be possible to use something like this to
optimize foreign key constraints, by not firing them if none of the
relevant columns have been updated?
There
Emmanuel Cecchet wrote:
Hi Jan,
Here is a new version of the patch with the following modifications:
- used oid list from pg_list.h
- properly handles triggers and generate an error if needed (updated doc
as well)
- added your test cases + extra bad trigger cases
Hi,
that got broken by
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
that got broken by the WHEN triggers patch
(c6e0a36243a54eff79b47b3a0cb119fb67a55165), which changed the
TriggerEnabled function signature, the code currently does not compile.
[ squint... ] What is that patch doing touching the
Florian G. Pflug f...@phlo.org writes:
It seems that pl/pgsql ignores the DEFAULT value of domains for local
variables.
The plpgsql documentation seems entirely clear on this:
The DEFAULT clause, if given, specifies the initial value assigned to
the variable when the block is
Bosco Rama postg...@boscorama.com writes:
According to the PG docs 'server' is a *non-reserved*
keyword. Does ecpg treat it as a reserved word?
Upon poking around in the ecpg sources, I discover that it has its own
list of unreserved keywords and pays no attention whatsoever to the
core
Tom Lane wrote:
Florian G. Pflug f...@phlo.org writes:
It seems that pl/pgsql ignores the DEFAULT value of domains for
local variables.
The plpgsql documentation seems entirely clear on this:
The DEFAULT clause, if given, specifies the initial value assigned to
the variable when the block
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
that got broken by the WHEN triggers patch
(c6e0a36243a54eff79b47b3a0cb119fb67a55165), which changed the
TriggerEnabled function signature, the code currently does not compile.
[ squint... ] What is that
Would a patch that changes that have any chance of being accepted? Or is
the gain (not having to repeat the DEFAULT clause, and being able to
maintain it at one place instead of many) considered too small compared
to the risk of breaking existing code?
I don't think there's a lot of risk of
2009/11/20 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Kris Jurka wrote:
On Fri, 20 Nov 2009, Magnus Hagander wrote:
I've cleaned up the git repo, and re-enabled the mirror script. From
what I can tell it works fine. In theory you will need to use force
mode if you pulled the
On Nov 20, 2009, at 10:50 PM, Tim Bunce wrote:
I'd suggest:
...; PL/Perl functions created with CREATE FUNCTION are called in a
scalar context, so can't return a list. You can return more complex
structures (arrays, records, and sets) by returning a reference, as
discussed
2009/11/20 Peter Eisentraut pete...@gmx.net:
On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote:
2009/11/20 Peter Eisentraut pete...@gmx.net:
On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote:
Is there any actual reason why we are building without thread safety
by default on
45 matches
Mail list logo
