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 more than
2009/7/29 Tom Lane t...@sss.pgh.pa.us:
Dean Rasheed dean.a.rash...@googlemail.com 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
Andres Freund and...@anarazel.de 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
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
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) definitions of these
On Wed, Jul 29, 2009 at 19:52, Kevin Fieldkevinjamesfi...@gmail.com 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
On Wed, Jul 29, 2009 at 23:31, Josh Williamsjoshwilli...@ij.net 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
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
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 that the
On Thu, Jul 30, 2009 at 12:17, Santosh Ahujacodes...@yahoo.com 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
2009/7/30 Pavel Stehule pavel.steh...@gmail.com:
2009/7/29 Brendan Jurd dire...@gmail.com:
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,
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 be
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
On Thu, Jul 30, 2009 at 12:17 PM, Euler Taveira de
Oliveiraeu...@timbira.com 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
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
2009/7/30 Pavel Stehule pavel.steh...@gmail.com:
2009/7/29 Brendan Jurd dire...@gmail.com:
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
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
2009/7/30 Pavel Stehule pavel.steh...@gmail.com:
2009/7/29 Brendan Jurd dire...@gmail.com:
I don't see any problem with extending this to allow up to 3 exponent
digits ...
2009/7/31 Euler Taveira de Oliveira eu...@timbira.com:
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
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Thu, Jul 30, 2009 at 12:46 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
Hmm. For what it's worth, I think Pavel makes a good point about
Brendan Jurd escreveu:
2009/7/31 Euler Taveira de Oliveira eu...@timbira.com:
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
2009/7/30 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurddire...@gmail.com wrote:
Hmm. For what it's worth, I think Pavel makes a good point about the
number of exponent
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Thu, Jul 30, 2009 at 1:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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
kar...@sao.ru (Sergey V. Karpov) writes:
Andres Freund and...@anarazel.de 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
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
On Thu, Jul 30, 2009 at 4:37 PM, Steve Prenticeprent...@cisco.com 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
--On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle
maili...@oopsware.de 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
--On Freitag, Juli 24, 2009 20:50:16 +0200 Bernd Helmle
maili...@oopsware.de 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.
Tom Lane wrote:
Steve Prentice prent...@cisco.com 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
On Thu, Jul 30, 2009 at 05:06:17PM -0400, Robert Haas wrote:
On Thu, Jul 30, 2009 at 4:37 PM, Steve Prenticeprent...@cisco.com 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
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
sure the
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
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, but
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 function, i.e. it
37 matches
Mail list logo
