Robert Haas wrote:
I think the best thing for this patch right now is to move it to
Returned with Feedback. I can't see any way that this patch is
going to be made committable for this CommitFest, and I think that
pretending otherwise is only encouraging KaiGai to do another of his
lighting
I am sorry for not elaborating on that. What I meant by de-correlation was
optimizing a query to get rid of sub-queirs by using joins.
eg. In the TPC-H schema, a query to find out the names of suppliers who
supply parts having size 100
*Query with nested subqueries:*
SELECT
S_NAME
FROM
2009/7/24 Tom Lane t...@sss.pgh.pa.us:
I think that WindowAgg does not need any changes because it already does
MemoryContextResetAndDeleteChildren(winstate-wincontext) at partition
boundaries. Hitoshi, do you agree?
I do. Looking closer, temporal space management of Agg is getting
similar
On Fri, Jul 24, 2009 at 04:12, Jaime
Casanovajcasa...@systemguards.com.ec wrote:
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Here's my first attempt at setting client_encoding automatically from
locale.
Sorry for the many mails on this
Excellent ... I'll try to have something tomorrow (Friday PDT) but I've got
some non-work related issues which may keep from giving this a good look until
the weekend (FWIW). I'll post any questions I have.
Thanks,
Greg W.
- Original Message
From: KaiGai Kohei kai...@ak.jp.nec.com
On Friday 24 July 2009 01:23:40 James Pye wrote:
Here are the features that I plan/hope to implement before submitting
any patch:
* Native Typing [Python types that represent Postgres types]
* Reworked function structure (Python modules, not function fragments)
* Improved SQL
Hi,
I'd still like to have opinion from one of the commiters on the
VIEW problem which also affects grant on all patch ( see
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00957.php ) and
I fear returned with feedback might prevent that until next commit fest.
I see potential for
On Jul 23, 2009, at 9:34 PM, Brendan Jurd wrote:
Well, a ROW is an ordered set of values, each one of which may be
either NULL or NOT NULL.
Right.
It doesn't really make sense to talk about the ROW itself being NULL
or NOT NULL, only its member values (but for extra confusion, contrast
with
David E. Wheeler wrote:
On Jul 23, 2009, at 9:34 PM, Brendan Jurd wrote:
I guess the spec authors figured they might as well make IS [NOT] NULL
do something useful when applied to a row rather than throwing an
error. I tend to agree.
Frankly, I find the state where a record with a NULL and
2009/7/24 David E. Wheeler da...@kineticode.com:
It's useful to learn that `ROW(NULL, NULL)` is NULL, but I find the whole
thing totally bizarre. Is it me?
*shrug* The IS [NOT] NULL tests mean something different when applied
to a ROW than they do when applied to a scalar value or an array.
On Jul 24, 2009, at 1:21 AM, Peter Eisentraut wrote:
While various of these ideas may be good, I think you are setting
yourself up
for a rejection.
Right, I supposed that that may be the case or at least that you would
feel this way based on your messages from the prior thread.
There
On Jul 17, 2009, at 04:27 , Robert Haas wrote:
- INNER joins are more complex because what happens on the inner side
of the join can potentially wipe out rows from the result. With a
LEFT join, it's sufficient to prove that the inner rel is at least
unique enough, but for an INNER join, we
Tom Lane wrote:
I don't personally have a problem with just forcing use of our own
erand48 on Cygwin; it's not a lot of code and it would make the behavior
of that build more like the MSVC build. But it's curious that such a
simple library function is seemingly broken on Cygwin ... especially
Does this also apply at the column level?
In Postgres is If column IS NOT NULL or If column IS NULL? Do all
columns in the record have to be NULL to have IF column IS NULL = true?
Best Regards
--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
904.592.5250
Brendan Jurd dire...@gmail.com writes:
So it is wrong to talk about ROW(NULL, NULL) being NULL. It doesn't
have the property of being NULL or not NULL, because it is a composite
value. ROW(NULL, NULL) IS NULL returns true, but that is not the
same as saying that it actually is NULL, because
Andrew Dunstan and...@dunslane.net writes:
It appears on Googling a bit that the erand48() is buggy in that it
requires the seed to have been initialized with srand48() or it will
constantly return 0.0.
Huh, and that sends us into an infinite loop? I'll take a look at that.
Even though it's
On Thu, Jul 23, 2009 at 06:46:25PM -0700, David E. Wheeler wrote:
Yes, but given that the standard says that `ROW(1, NULL)` is NULL, then I
would expect it to be NOT DISTINCT from `ROW(2, NULL)`.
Wait, didn't we decide upthread that the standard said ROW(1, NULL) isn't
NULL?
(From Tom):
This
On Fri, Jul 24, 2009 at 7:53 AM, Alex Brasetvika...@brasetvik.com wrote:
On Jul 17, 2009, at 04:27 , Robert Haas wrote:
- INNER joins are more complex because what happens on the inner side
of the join can potentially wipe out rows from the result. With a
LEFT join, it's sufficient to prove
Joshua Tolley eggyk...@gmail.com writes:
On Thu, Jul 23, 2009 at 06:46:25PM -0700, David E. Wheeler
Yes, but given that the standard says that `ROW(1, NULL)` is NULL, then I
would expect it to be NOT DISTINCT from `ROW(2, NULL)`.
Wait, didn't we decide upthread that the standard said ROW(1,
mahendra chavan mah...@gmail.com wrote:
What I meant by de-correlation was optimizing a query to get rid of
sub-queirs by using joins.
eg. In the TPC-H schema, a query to find out the names of suppliers
who supply parts having size 100
*Query with nested subqueries:*
SELECT
I wrote:
Andrew Dunstan and...@dunslane.net writes:
It appears on Googling a bit that the erand48() is buggy in that it
requires the seed to have been initialized with srand48() or it will
constantly return 0.0.
Huh, and that sends us into an infinite loop? I'll take a look at that.
Even
Tom Lane wrote:
I wrote:
Andrew Dunstan and...@dunslane.net writes:
It appears on Googling a bit that the erand48() is buggy in that it
requires the seed to have been initialized with srand48() or it will
constantly return 0.0.
Huh, and that sends us into an infinite
daveg da...@sonic.net wrote:
On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
maybe make a separate column called idle that's a boolean,
or something, and let the query column contain the most recent
query (whether or not it's still executing).
+1
I like this idea a lot.
On Fri, Jul 24, 2009 at 10:47 AM, Kevin
Grittnerkevin.gritt...@wicourts.gov wrote:
daveg da...@sonic.net wrote:
On Thu, Jun 04, 2009 at 10:22:41PM -0400, Robert Haas wrote:
maybe make a separate column called idle that's a boolean,
or something, and let the query column contain the most
Robert Haas robertmh...@gmail.com wrote:
Hmm, I don't think we'd need two columns for this, actually. You
could just have one column last_statement_endtime (not sure if it's
the best name, but something along those lines) which would be NULL
if the statement was still in progress and the
Robert Haas robertmh...@gmail.com writes:
Hmm, I don't think we'd need two columns for this, actually. You
could just have one column last_statement_endtime (not sure if it's
the best name, but something along those lines) which would be NULL if
the statement was still in progress and the
Thank you for you response. I was looking for a query rewriting mechanism
which would be outside the optimizer and will do this kind of
transformations at the query level.
~Mahendra
On Fri, Jul 24, 2009 at 7:32 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
mahendra chavan
Bernd Helmle maili...@oopsware.de writes:
I've attached a slightly edited patch which fixes a compiler warning in
encode.c, too.
Bernd, are you done reviewing this or did you intend to do more?
It's still marked as needs review on the commitfest page.
regards, tom lane
On Fri, 2009-07-24 at 09:31 -0400, Tom Lane wrote:
Brendan Jurd dire...@gmail.com writes:
It's worse than that, because there actually is also such a thing as
the row value being NULL --- ie, there's no row structure at all.
At least internally, that's a completely different thing from having
Hi all,
I have some issues to compile uuid contrib of 8.4 version.
Touching something i see that the gmake don't find uuid.h.
(pfexec gmake -d)
Touching more, i add uuid.h into the uuid directory and i had a
error message: missing separator.
So i google a little and i find something:
On Fri, Jul 24, 2009 at 11:15 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm, I don't think we'd need two columns for this, actually. You
could just have one column last_statement_endtime (not sure if it's
the best name, but something along those lines)
On Fri, Jul 24, 2009 at 09:31:13AM -0400, Tom Lane wrote:
Brendan Jurd dire...@gmail.com writes:
So it is wrong to talk about ROW(NULL, NULL) being NULL. It doesn't
have the property of being NULL or not NULL, because it is a composite
value. ROW(NULL, NULL) IS NULL returns true, but that
Emanuel Calvo Franco escribió:
Hi all,
I have some issues to compile uuid contrib of 8.4 version.
Touching something i see that the gmake don't find uuid.h.
(pfexec gmake -d)
Touching more, i add uuid.h into the uuid directory and i had a
error message: missing separator.
Did you use
Hi all,
I have some issues to compile uuid contrib of 8.4 version.
Touching something i see that the gmake don't find uuid.h.
(pfexec gmake -d)
Touching more, i add uuid.h into the uuid directory and i had a
error message: missing separator.
Did you use gmake the second time? What was
On Fri, 2009-07-24 at 04:24 -0700, James Pye wrote:
I see Python 3 as a good opportunity to change the interfaces and fix
the design of the PL.
I dunno. I have time to give it some TLC, and I'm not terribly excited
about trying to tack features onto something that I find kinda gross.
Sam Mason s...@samason.me.uk wrote:
On Fri, Jul 24, 2009 at 09:31:13AM -0400, Tom Lane wrote:
Hope nobody minds if I go off on a somewhat pedagogic bent here!
Not as long as you don't mind replies in kind. ;-)
The fact that it happens to be a NULL *value* in one case
Well, according
On Wed, 2009-07-22 at 12:25 +0100, Dean Rasheed wrote:
OK, here's an updated patch.
One thing that Alvaro mentioned that you didn't do yet is use the macro
to return from the function (either PG_RETURN_VOID() or
PG_RETURN_NULL()).
You seem to be following the document here:
On Fri, Jul 24, 2009 at 5:15 AM, David E. Wheelerda...@kineticode.com wrote:
On Jul 23, 2009, at 9:34 PM, Brendan Jurd wrote:
Well, a ROW is an ordered set of values, each one of which may be
either NULL or NOT NULL.
Right.
It doesn't really make sense to talk about the ROW itself being
On Fri, Jul 24, 2009 at 1:35 PM, Merlin Moncuremmonc...@gmail.com wrote:
On Fri, Jul 24, 2009 at 5:15 AM, David E. Wheelerda...@kineticode.com wrote:
On Jul 23, 2009, at 9:34 PM, Brendan Jurd wrote:
Well, a ROW is an ordered set of values, each one of which may be
either NULL or NOT NULL.
Jeremy Kerr j...@ozlabs.org writes:
Currently, libpq will wrap each send() call on the connection with
two system calls to mask SIGPIPEs. This results in 3 syscalls instead
of one, and (on Linux) can lead to high contention on the signal
mask locks in threaded apps.
We have a couple of other
Merlin Moncure mmonc...@gmail.com writes:
I think the following should _not_ return true:
select (null, null)::somerowtype is null;
Take it up with the SQL standards committee. The spec is 100% not
ambiguous about this.
regards, tom lane
--
Sent via pgsql-hackers
Jeff Davis pg...@j-davis.com writes:
There's no single test, but you can see if it's an empty row with:
x IS NULL AND x IS DISTINCT FROM NULL
And you can see if it's a real NULL by:
x IS NULL AND x IS NOT DISTINCT FROM NULL
Hmmm ... that suggests that we may not be handling IS DISTINCT
On Jul 24, 2009, at 3:17, Brendan Jurd dire...@gmail.com wrote:
ROW(NULL, NULL) IS NULL returns true, but that is not the
same as saying that it actually is NULL
I think my head just exploded. Loving the dark corners of SQL…
Best,
David
--
Sent via pgsql-hackers mailing list
On Jul 24, 2009, at 11:10, Tom Lane t...@sss.pgh.pa.us wrote:
Hmmm ... that suggests that we may not be handling IS DISTINCT FROM
correctly for rowtypes. I haven't read that part of the spec, but
I would've guessed that the spec wants it to be consistent with
IS NULL.
Yes, that's precisely
On Fri, 2009-07-24 at 13:35 -0400, Merlin Moncure wrote:
I think the following should _not_ return true:
select (null, null)::somerowtype is null;
The reasoning being that
It's not at all clear to me that you can reason effectively about SQL
logic semantics. Upon which laws are you
On Fri, 2009-07-24 at 14:10 -0400, Tom Lane wrote:
Hmmm ... that suggests that we may not be handling IS DISTINCT FROM
correctly for rowtypes. I haven't read that part of the spec, but
I would've guessed that the spec wants it to be consistent with
IS NULL.
Our behavior appears to match
--On Freitag, Juli 24, 2009 11:38:06 -0400 Tom Lane t...@sss.pgh.pa.us
wrote:
Bernd, are you done reviewing this or did you intend to do more?
It's still marked as needs review on the commitfest page.
I hoped to get more profiling data like Andrew suggested, but haven't
enough time to do it
On Fri, Jul 24, 2009 at 2:05 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
I think the following should _not_ return true:
select (null, null)::somerowtype is null;
Take it up with the SQL standards committee. The spec is 100% not
ambiguous about this.
I'm
Hi!
I have a simple one-line patch to enable the use of multiple CPUs or
cores when building with MSVC. It is only inside the C compiler
itself, but it makes about a 30-35% reduction in compile time on a
fairly CPU-limited dual-CPU VM. It would probably do a lot more on for
example a quadcore. It
On Wed, Jul 22, 2009 at 8:57 AM, Magnus Hagandermag...@hagander.net wrote:
On Wed, Jul 22, 2009 at 14:53, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Yup, you would need a protocol change that would allow the client to
change its mind about what the username
On Fri, Jul 24, 2009 at 8:07 PM, Magnus Hagandermag...@hagander.net wrote:
I'm going to apply this for HEAD. I'm considering backpatching as
well, to speed up all build machines. Comments on that?
Let's see how it goes in the BF for HEAD, and then backpatch if it
looks good. I'm keen to get
On Thursday 23 July 2009 13:29:51 Andreas Wenk wrote:
attached you can find an updated patch. The changes are:
- change \du and \dg to \du+ and \dg+ in the docu
- change the same in psql/help.c
- change the translation files in psql/po
Fixed, thanks.
--
Sent via pgsql-hackers mailing list
Robert Haas robertmh...@gmail.com writes:
OK, here it is again. Changes are the same as the previous version,
but this one should apply cleanly after today's pgindent run.
As I was poking through this I noticed that it makes at least one small
change in the output format: what had been
On Thu, Jul 23, 2009 at 09:04, Magnus Hagandermag...@hagander.net wrote:
On Thu, Jul 23, 2009 at 08:04, Tsutomu Yamadatsut...@sraoss.co.jp wrote:
Hello,
Thank you for correcting patch.
However, I think the following block have to use VirualFree*Ex*().
(yes, this should never happen, maybe
On Friday 26 June 2009 12:07:24 Tsutomu Yamada wrote:
Included is a conceptual patch to use intptr_t. Comments are welcome.
After closer inspection, not having a win64 box available, I have my doubts
whether this patch actually does anything. Foremost, it doesn't touch the
definition of the
On Fri, Jul 24, 2009 at 7:49 PM, Merlin Moncuremmonc...@gmail.com wrote:
Still, why:
*) is select null::foo is distinct from (null, null)::foo; true?
(null should not be distinct from null)
*) does (null, null) allow STRICT functions to execute?
*) is (null, null)::text not null?
These
On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Hey, this is really cool. Think it is a nice introduction. Fixed some
of the really obvious language stuff and an
Robert Haas robertmh...@gmail.com writes:
OK, here it is again. Changes are the same as the previous version,
but this one should apply cleanly after today's pgindent run.
Applied with some minor editorialization/further cleanup.
I left the Subquery Scan on ss business as-is. If anyone
On Fri, Jul 24, 2009 at 4:02 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
OK, here it is again. Changes are the same as the previous version,
but this one should apply cleanly after today's pgindent run.
As I was poking through this I noticed that it makes
On Fri, Jul 24, 2009 at 5:11 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
OK, here it is again. Changes are the same as the previous version,
but this one should apply cleanly after today's pgindent run.
Applied with some minor editorialization/further
On Fri, Jul 24, 2009 at 4:29 PM, Greg Starkgsst...@mit.edu wrote:
On Fri, Jul 24, 2009 at 7:49 PM, Merlin Moncuremmonc...@gmail.com wrote:
Still, why:
*) is select null::foo is distinct from (null, null)::foo; true?
(null should not be distinct from null)
*) does (null, null) allow STRICT
Didn't we just clean up a mess in our XML handling to do with memory
handlers? It looks like contrib/xml2 might have similar problems. Here's
the relevant part of a back trace from a core dump:
Program terminated with signal 11, Segmentation fault.
#0 0x0069300a in pfree ()
(gdb) bt
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
After closer inspection, not having a win64 box available, I have my doubts
whether this patch actually does anything. Foremost, it doesn't touch the
definition of the Datum type, which ought to be at the core of a change like
this.
Do
On Fri, Jul 24, 2009 at 23:11, Robert Haasrobertmh...@gmail.com wrote:
On Fri, Jul 24, 2009 at 4:02 PM, Tom Lanet...@sss.pgh.pa.us wrote:
This is not likely to matter to human readers but it might to programs.
OTOH we presumably expect programs to migrate to using a more
program-friendly
On Fri, Jul 24, 2009 at 10:35 PM, Stephen Frostsfr...@snowman.net wrote:
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
After closer inspection, not having a win64 box available, I have my doubts
whether this patch actually does anything. Foremost, it doesn't touch the
definition of the
Attached is my patch to enable SSPI on cygwin.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--- origsrc/postgresql-8.4.0/configure.in 2009-06-27 02:14:47.0 +0200
+++ src/postgresql-8.4.0/configure.in 2009-07-02 09:02:25.921875000 +0200
@@ -907,7 +907,11 @@ if test $with_gssapi
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
On Fri, Jul 24, 2009 at 10:35 PM, Stephen Frostsfr...@snowman.net wrote:
Do you need access to a Win64 box? I can provide you access to a
Win64 system, which Dave Page and Magnus already have access to, if it
would be useful..
I haven't got
On Fri, Jul 24, 2009 at 23:47, Reini Urbanrur...@x-ray.at wrote:
Attached is my patch to enable SSPI on cygwin.
Is it really such a good idea to keep doing #define WIN32 and #undef
WIN32 in multiple places? It seems very fragile to me - we should keep
the defines for cygwin and win32 separate.
On Jul 24, 2009, at 9:40 AM, Jeff Davis wrote:
There's no single test, but you can see if it's an empty row with:
x IS NULL AND x IS DISTINCT FROM NULL
And you can see if it's a real NULL by:
x IS NULL AND x IS NOT DISTINCT FROM NULL
It's funny until you try it -- then it's just scary.
Reini,
the style of this patch has previously been criticized by both Magnus
and me.
We do not define WIN32 *anywhere* in our sources, and we don't want to
start. In fact, IIRC we carefully removed all such code years ago,
because it caused us lots of grief.
Please find a way to code
On Jul 24, 2009, at 11:37 AM, Jeff Davis wrote:
Hmmm ... that suggests that we may not be handling IS DISTINCT FROM
correctly for rowtypes. I haven't read that part of the spec, but
I would've guessed that the spec wants it to be consistent with
IS NULL.
Our behavior appears to match the
On Fri, Jul 24, 2009 at 12:30:39PM -0500, Kevin Grittner wrote:
Sam Mason s...@samason.me.uk wrote:
The fact that it happens to be a NULL *value* in one case
Well, according to Codd (and I tend to go with him on this) there is
no such thing. NULL is a way to flag a place where a value
Andrew Dunstan and...@dunslane.net writes:
Didn't we just clean up a mess in our XML handling to do with memory
handlers? It looks like contrib/xml2 might have similar problems.
Yeah, it's using xmlMemSetup(), and being even less careful than the
core code was :-(.
Do we feel like fixing it,
Martijn van Oosterhout wrote:
On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Hey, this is really cool. Think it is a nice introduction. Fixed some
of the really
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Didn't we just clean up a mess in our XML handling to do with memory
handlers? It looks like contrib/xml2 might have similar problems.
Yeah, it's using xmlMemSetup(), and being even less careful than the
core code was :-(.
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Thanks for this, it really does help, I believe. I've been reviewing it
and am also planning on helping refine and improve
On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frostsfr...@snowman.net wrote:
Thanks for this, it really does help, I believe. I've been reviewing it
and am also planning on helping refine and improve upon it. I'd like to
spend time working on the patch as well but I'm hesitant to commit to
that
On Jul 24, 2009, at 2:59 PM, David E. Wheeler wrote:
FETCH have INTO rec_have;
FETCH want INTO rec_want;
WHILE NOT rec_have IS NULL OR NOT rec_want IS NULL LOOP
IF rec_have IS DISTINCT FROM rec_want THEN
RETURN false;
END IF;
rownum = rownum + 1;
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Jul 22, 2009 at 2:20 AM, Robert Haasrobertmh...@gmail.com wrote:
Are you planning to update this patch based on Martin's review?
Sure. Attached is an updated patch.
I looked at this patch. I don't see how we can consider accepting it
by
Josh Berkus wrote:
Stuff someone else should do:
a. review code
b. review code format
I am done with this review.
I have reviewed this and made a small tweak in the docco. I'm just about
ready to commit this, but I'm still slightly worried that passing NULL
to denote all columns in this
Andrew Dunstan and...@dunslane.net writes:
I have reviewed this and made a small tweak in the docco. I'm just about
ready to commit this, but I'm still slightly worried that passing NULL
to denote all columns in this piece of grammar:
| FORCE QUOTE '*'
{
I wrote:
I am also thinking that if you do need the ability to get control back
without blocking on the socket, you probably will need that for writes
as well as reads; and this patch doesn't cover the write case.
Oh, another gripe: I'll bet a nickel that this doesn't work very nicely
under
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
Thanks, but I found an incorrect change at the trusted procedure section.
Old)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
- SECURITY_LABEL =
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have reviewed this and made a small tweak in the docco. I'm just about
ready to commit this, but I'm still slightly worried that passing NULL
to denote all columns in this piece of grammar:
| FORCE QUOTE
Sam Mason wrote:
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
Thanks, but I found an incorrect change at the trusted procedure section.
Old)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
-
Tom Lane wrote:
Mark Kirkwood mar...@paradise.net.nz writes:
Yeah, enabling log_lock_waits is certainly another approach, however you
currently miss out on those that are deadlock_timeout - and
potentially they could be the source of your problem (i.e millions of
waits all
On Fri, Jul 24, 2009 at 10:53 PM, Stephen Frostsfr...@snowman.net wrote:
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
On Fri, Jul 24, 2009 at 10:35 PM, Stephen Frostsfr...@snowman.net wrote:
Do you need access to a Win64 box? I can provide you access to a
Win64 system, which Dave Page and
Mark Kirkwood wrote:
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark
Kirkwoodmar...@paradise.net.nz wrote:
With respect to the sum of wait times being not very granular, yes -
quite
true. I was thinking it is useful to be able to answer the question
'where
is my wait time being
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have a row
in the
On Fri, Jul 24, 2009 at 7:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Jul 22, 2009 at 2:20 AM, Robert Haasrobertmh...@gmail.com wrote:
Are you planning to update this patch based on Martin's review?
Sure. Attached is an updated patch.
I looked
Sam Mason wrote:
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have
On Sun, Jul 19, 2009 at 06:13:32PM +0200, Petr Jelinek wrote:
Hello,
while writing some basic docs I found bug in dependency handling when
doing SET on object type that already had some default privileges.
Attached patch fixes it, it also fixes thinko in parser (DROPing GRANT
OPTION
On Fri, Jul 24, 2009 at 5:23 AM, James Pyeli...@jwp.name wrote:
That also means that maintaining a separate, parallel code base
for a Python 3 variant can only be acceptable if it gives major
advantages.
I'm not particularly interested in Python 3.x support yet (we are still back on
On Thu, Jun 25, 2009 at 11:18 AM, Michael Meskesmes...@postgresql.org wrote:
On Wed, Jun 24, 2009 at 11:51:57AM +0200, Boszormenyi Zoltan wrote:
attached is our latest patch extending ECPG:
Just as a short explanation, the older versions were sent to me only and I
reviewed them. I haven't
On Jul 24, 2009, at 7:08 PM, Stuart Bishop wrote:
I'm not particularly interested in Python 3.x support yet (we are
still back on 2.4, soon to hop to 2.5 or 2.6. For us 3.1 is probably
2 years away at the earliest). I am interested in improved plpython
though.
Two years would hopefully be
Hello
I have one idea, that should simplify string to char array
transformation. The base is idea: between every char is empty string,
so empty string is regular separator for string_to_array function.
This behave is inversion of array_to_string function behave:
postgres=# select
96 matches
Mail list logo
