2009/7/30 Steve Prentice :
> Since I didn't get completely shot out of the water and a couple people
> seemed to think it was helpful, I'm submitting this patch for consideration
> in the next commitfest.
>
> This patch changes plpgsql IN parameters so they are mutable. Previously,
> they were bein
2009/7/31 Bernd Helmle :
> --On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle
> wrote:
>
>>> Hi,
>>>
>>> I sending a little bit modified version - I removed my forgotten
>>> comment in gram.y
>>
>> Thanks, i'll look on it asap.
>
> Looks good now.
>
> Here is a slightly edited reviewed patch v
As Peter Eisentraut pointed out, we are not on the phase
to discuss about user documentations yet.
It is a reasonable idea to discuss correct specifications
of SE-PostgreSQL from the viewpoint of the developers.
Then, it will the a good source for the upcoming user docs.
For the recent a few days
On Thu, 2009-07-30 at 21:45 -0400, Andrew Dunstan wrote:
> > For instance, what would it mean if y
> > SELECT foo(a) FROM mytable;
> >
> > Where foo() mutated it's IN argument? Would that really be an UPDATE?
> >
> No, surely the mutated value will only be visible within the scope of
> the functio
On Jul 29, 2009, at 12:12 PM, Andrew Dunstan wrote:
As I said upthread, I think we can easily provide some extra
convenience functions which will do what you want. The only thing I
was really arguing about was the function name for such a gadget.
+1.
"xpath_string" does seem unfortunate, bu
Jeff Davis wrote:
If mutable IN parameters were allowed, I don't even think it could be
allowable to call them from the SQL level, you could only from another
function.
For instance, what would it mean if you did something like:
SELECT foo(a) FROM mytable;
Where foo() mutated it's IN argumen
On Thu, 2009-07-30 at 17:40 -0700, David Fetter wrote:
> > > This patch changes plpgsql IN parameters so they are mutable. Previously,
> > > they were being forced constant. This patch modifies the plpgsql.sql
> > > regression test and corresponding .out file. The regression test also
> > > makes
On Thu, Jul 30, 2009 at 05:06:17PM -0400, Robert Haas wrote:
> On Thu, Jul 30, 2009 at 4:37 PM, Steve Prentice wrote:
> > Since I didn't get completely shot out of the water and a couple people
> > seemed to think it was helpful, I'm submitting this patch for consideration
> > in the next commitfes
Tom Lane wrote:
> Steve Prentice writes:
> > On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote:
> >> Tom added a comment in 1995
>
> > For the record, I meant 2005.
>
> I was intending to say something like "I've been around this project
> a long time, but not THAT long" ...
I was looking at a
--On Freitag, Juli 24, 2009 20:50:16 +0200 Bernd Helmle
wrote:
I don't believe i can do very much this weekend...
I have to delay that until sunday, but will get my hands on some
performance and function tests again, since i have access on the customer
machine then.
--
Thanks
--On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle
wrote:
Hi,
I sending a little bit modified version - I removed my forgotten
comment in gram.y
Thanks, i'll look on it asap.
Looks good now.
Here is a slightly edited reviewed patch version. I've edited the docs and
fixed some spelli
On Thu, Jul 30, 2009 at 4:37 PM, Steve Prentice wrote:
> Since I didn't get completely shot out of the water and a couple people
> seemed to think it was helpful, I'm submitting this patch for consideration
> in the next commitfest.
>
> This patch changes plpgsql IN parameters so they are mutable.
Since I didn't get completely shot out of the water and a couple
people seemed to think it was helpful, I'm submitting this patch for
consideration in the next commitfest.
This patch changes plpgsql IN parameters so they are mutable.
Previously, they were being forced constant. This patch m
kar...@sao.ru (Sergey V. Karpov) writes:
> Andres Freund writes:
>> Looks nice. The only small gripe I have is that the patch adds trailing
>> whitespaces at a lot of places...
> My fault. Please check the patch version attached - I've tried to fix
> all those.
I did some minor cleanup on this
Tom Lane wrote:
> I think we've pretty much established that it doesn't make things
> *worse*, so I'm sort of inclined to go ahead and apply it. The
> theoretical advantage of eliminating O(N^2) search behavior seems
> like reason enough, even if it takes a ridiculous number of tables
> for th
On Thu, Jul 30, 2009 at 1:24 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> The timings vary by up to 2.5% between runs, so that's the noise
>> level. Five runs of each (alternating between the two) last night
>> give an average performance of 1.89% faster for the patched version.
>> Combining
"Kevin Grittner" writes:
> The timings vary by up to 2.5% between runs, so that's the noise
> level. Five runs of each (alternating between the two) last night
> give an average performance of 1.89% faster for the patched version.
> Combining that with yesterday's results starts to give me prett
2009/7/30 Tom Lane :
> Pavel Stehule writes:
>> 2009/7/30 Robert Haas :
>>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
Hmm. For what it's worth, I think Pavel makes a good point about the
number of exponent digits -- a large chunk of the use case for numeric
formatting wo
Brendan Jurd escreveu:
> 2009/7/31 Euler Taveira de Oliveira :
>> Brendan Jurd escreveu:
>>> Limiting to two exponent digits also has the nice property that the
>>> output always matches the length of the format pattern:
>>>
>>> 9.99
>>> 1.23E+02
>>>
>> I don't think neglecting to represent a v
On Thu, Jul 30, 2009 at 12:46 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> 2009/7/30 Robert Haas :
>>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
Hmm. For what it's worth, I think Pavel makes a good point about the
number of exponent digits -- a large chunk of the use case f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
> Robert Haas writes:
>> ... One thing I have belatedly realized about this
>> CommitFest is that we (or at least, I) did not think about asking the
>> committers about their schedules, and it turns out that three of them
>> - Heikki
Pavel Stehule writes:
> 2009/7/30 Robert Haas :
>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
>>> Hmm. For what it's worth, I think Pavel makes a good point about the
>>> number of exponent digits -- a large chunk of the use case for numeric
>>> formatting would be fixed-width reporting
2009/7/31 Euler Taveira de Oliveira :
> Brendan Jurd escreveu:
>> Limiting to two exponent digits also has the nice property that the
>> output always matches the length of the format pattern:
>>
>> 9.99
>> 1.23E+02
>>
> I don't think neglecting to represent a valid number is a "nice property".
2009/7/30 Robert Haas :
> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
>> 2009/7/30 Pavel Stehule :
>>> 2009/7/29 Brendan Jurd :
I don't see any problem with extending this to allow up to 3 exponent
digits ... Pavel, any comment?
>>>
>>> I am not sure - this function should be us
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
> 2009/7/30 Pavel Stehule :
>> 2009/7/29 Brendan Jurd :
>>> I don't see any problem with extending this to allow up to 3 exponent
>>> digits ... Pavel, any comment?
>>
>> I am not sure - this function should be used in reports witl fixed
>> line
On Thu, Jul 30, 2009 at 12:17 PM, Euler Taveira de
Oliveira wrote:
> Brendan Jurd escreveu:
>> I can't imagine anyone reading the code getting confused about this,
>> and don't know how to go about writing a comment explaining something
>> that is intuitively obvious to me. I don't understand what
Brendan Jurd escreveu:
> I can't imagine anyone reading the code getting confused about this,
> and don't know how to go about writing a comment explaining something
> that is intuitively obvious to me. I don't understand what aspect of
> it requires explanation. The test is not in the switch bec
Brendan Jurd escreveu:
> Hmm. For what it's worth, I think Pavel makes a good point about the
> number of exponent digits -- a large chunk of the use case for numeric
> formatting would be fixed-width reporting.
>
But it doesn't cover all numbers in the interval. And in this case, all
numbers can
2009/7/30 Euler Taveira de Oliveira :
>> So if you put the test inside the switch, it would need to appear in
>> every single branch of the switch except for the NUM_E one. I'm
>> confused about why you think this needs a comment. Perhaps I
>> misunderstood you?
>>
> Yes, I know you need to modif
"Kevin Grittner" wrote:
> with the default settings, the patched version ran an additional 1%
> faster than the unpatched; although I don't have enough samples to
> have a high degree of confidence it wasn't noise. I'll run another
> slew of tests tonight with the existing dump file to confirm
2009/7/30 Pavel Stehule :
> 2009/7/29 Brendan Jurd :
>> I don't see any problem with extending this to allow up to 3 exponent
>> digits ... Pavel, any comment?
>
> I am not sure - this function should be used in reports witl fixed
> line's width. And I am thinking, so it's should be problem - I pre
On Thu, Jul 30, 2009 at 12:17, Santosh Ahuja wrote:
> Compilation fails with the following errors.
>
>
> C:\Program Files\Microsoft Visual Studio 8\VC\include\sys/types.h(23):
> fatal error C1189: #error : ERROR: Only Win32 target supported!
>
> This seems something very trivial but I have
Alvaro Herrera írta:
> Boszormenyi Zoltan wrote:
>
>
>> The vague consensus for syntax options was that the GUC
>> 'lock_timeout' and WAIT [N] extension (wherever NOWAIT
>> is allowed) both should be implemented.
>>
>> Behaviour would be that N seconds timeout should be
>> applied to every lock
Compilation fails with the following errors.
C:\Program Files\Microsoft Visual Studio 8\VC\include\sys/types.h(23):
fatal error C1189: #error : ERROR: Only Win32 target supported!
This seems something very trivial but I have'nt been able to figure it out yet
I use MSVC 2005 M
On Wed, Jul 29, 2009 at 23:31, Josh Williams wrote:
> On Tue, 2009-07-28 at 23:38 -0400, Josh Williams wrote:
>> Huh, running the patched version on a single thread with 128 clients
>> just got it to crash. Actually consistently, three times now. Will try
>> the same thing on the development box
On Wed, Jul 29, 2009 at 19:52, Kevin Field wrote:
> On Win2k3 Std SP2, the service won't start once I've applied the
> patch. In the log, I get:
>
> %t LOG: CreateProcess call failed: A blocking operation was
> interrupted by a call to WSACancelBlockingCall.
Now, that's just strange :-O
First o
Peter Eisentraut wrote:
> On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote:
>> Peter Eisentraut wrote:
>>> On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definition
On Wednesday 29 July 2009 20:16:48 decibel wrote:
> bytea doesn't cast well to and from text when you're dealing with hex
> data; you end up using the same amount of space as a varchar. What
> would probably work well is a hex datatype that internally works like
> bytea but requires that the input
Andres Freund writes:
Hi Andres,
> Looks nice. The only small gripe I have is that the patch adds trailing
> whitespaces at a lot of places...
>
> Except maybe that I do see no need for changes anymore...
My fault. Please check the patch version attached - I've tried to fix
all those.
Thanks,
2009/7/29 Tom Lane :
> Dean Rasheed writes:
>> [ deferrable unique constraints patch ]
>
> Applied after rather extensive editorialization.
Excellent! Thanks for all your work sorting out my rookie mistakes. I
haven't had a chance to go through all your "editorializations" in
detail yet, but I'm
Tom Lane wrote:
>>> Is there a reason we force plpgsql IN parameters to constant?
>
> Now having said all that, I'm not really in favor of Steve's
> proposal --- it seems like it mostly would be encouraging dubious
> programming practices. But it's hard to say that the arguments
> against are mor
41 matches
Mail list logo
