2009/11/20 Peter Eisentraut :
> On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote:
>> 2009/11/20 Peter Eisentraut :
>> > 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?
>>
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
>discusse
2009/11/20 Heikki Linnakangas :
> 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 re
> 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
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 th
Tom Lane wrote:
"Florian G. Pflug" 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 entered. I
Bosco Rama 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 grammar's unreserved_keyw
"Florian G. Pflug" 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 entered. If
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 innards of
trigger.c
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 broke
On Fri, Nov 20, 2009 at 5:05 PM, Tom Lane wrote:
> Robert Haas 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;
Robert Haas 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 RI_FKey_keyequal_upd_pk.
On Fri, Nov 20, 2009 at 3:38 PM, Tom Lane 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 for AFTER
> t
Jan Wieck writes:
> On 11/20/2009 1:12 AM, Tom Lane wrote:
>> Jan Wieck 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 ... not sure why. Specific
Andreas Pflug 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 option was ex
Itagaki Takahiro 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 parsing logic to enforce that.
On Fri, Nov 20, 2009 at 2:44 PM, Heikki Linnakangas
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
>>> mode if you pulled t
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 messa
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 :(
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 wh
-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 fo
On Fri, Nov 20, 2009 at 12:51 PM, Florian G. Pflug wrote:
> Robert Haas wrote:
>>
>> On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug 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 correspondin
Robert Haas wrote:
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug 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 in a
PLpgSQL_ex
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
On Sun, 2009-11-15 at 17:17 -0500, Tom Lane wrote:
> Josh Berkus 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 broken, I would
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
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 fut
On Thu, Nov 19, 2009 at 9:06 PM, Florian G. Pflug 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$
> decl
On Fri, Nov 20, 2009 at 2:08 AM, Simon Riggs wrote:
> On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
>> On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote:
>> > Hi,
>> >
>> > Robert Haas wrote:
>> >>
>> >> Settling on a syntax, and an internal representation for that syntax,
>> >
>> > I'
On Fri, Nov 20, 2009 at 7:31 AM, Heikki Linnakangas
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 2008; hackers; you, me and
Tom Lane wrote:
Kenneth Marshall 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 years. There'
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 use
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
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 will/shou
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
> a
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, Services
Joachim Wieland wrote:
> On Thu, Nov 19, 2009 at 11:04 PM, Joachim Wieland 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, effectively copying
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 Postgre
Joachim Wieland wrote:
> On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
> 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 b
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 pg
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
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 be
> recovered from there and
On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote:
> 2009/11/20 Peter Eisentraut :
> > 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 pla
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?
>
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 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
45 matches
Mail list logo
