On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagander wrote:
>>
>> 1) it introduces a dependency for -lpgport when compiling a client
>> that uses libpq
>> http://archives.postgresql.org/pgsql-hackers/2009-07/msg01511.php
>
> For other parts of libpgport that are needed, we pull in the
> individual s
2009/7/24 Euler Taveira de Oliveira :
> Here is my review. The patch applied without problems. The docs and regression
> tests are included. Both of them worked as expected. Also, you included a fix
> in RN format, do it in another patch.
>
Well, I updated an error message for RN to keep it consis
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 array_to_string(
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
On Thu, Jun 25, 2009 at 11:18 AM, Michael Meskes 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 found time to to re
On Fri, Jul 24, 2009 at 5:23 AM, James Pye 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
2.4, soon to hop
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
> OPTI
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 a
On Fri, Jul 24, 2009 at 7:21 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas 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 ac
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
Mark Kirkwood wrote:
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark
Kirkwood 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 spent' - but it hides c
On Fri, Jul 24, 2009 at 10:53 PM, Stephen Frost wrote:
> Dave,
>
> * Dave Page (dp...@pgadmin.org) wrote:
>> On Fri, Jul 24, 2009 at 10:35 PM, Stephen Frost 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 acces
Tom Lane wrote:
Mark Kirkwood 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 < deadlock_timeout but taken together
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)
- SECURITY_LABE
Tom Lane wrote:
Andrew Dunstan 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 '*'
{
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 =
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
Andrew Dunstan 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 '*'
> {
>
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
Fujii Masao writes:
> On Wed, Jul 22, 2009 at 2:20 AM, Robert Haas 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 itself. It adds a bunch of code that is not
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;
F
On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frost 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 right now due to
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 u
Tom Lane wrote:
Andrew Dunstan 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 fixi
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 t
Andrew Dunstan 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, or is it time to r
On Fri, Jul 24, 2009 at 12:30:39PM -0500, Kevin Grittner wrote:
> Sam Mason 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 could be
> store
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 stan
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 your
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.
Am
On Fri, Jul 24, 2009 at 23:47, Reini Urban 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. Even if that mea
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> On Fri, Jul 24, 2009 at 10:35 PM, Stephen Frost 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 round to i
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
On Fri, Jul 24, 2009 at 10:35 PM, Stephen Frost 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 Datum typ
On Fri, Jul 24, 2009 at 23:11, Robert Haas wrote:
> On Fri, Jul 24, 2009 at 4:02 PM, Tom Lane 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 EXPLAIN output format with 8.5.
>>
>>
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.
D
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
On Fri, Jul 24, 2009 at 4:29 PM, Greg Stark wrote:
> On Fri, Jul 24, 2009 at 7:49 PM, Merlin Moncure 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?
On Fri, Jul 24, 2009 at 5:11 PM, Tom Lane wrote:
> Robert Haas 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.
Thanks. I mostly finished
On Fri, Jul 24, 2009 at 4:02 PM, Tom Lane wrote:
> Robert Haas 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 th
Robert Haas 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 complains
it would be a
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
On Fri, Jul 24, 2009 at 7:49 PM, Merlin Moncure 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 are all good
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 D
On Thu, Jul 23, 2009 at 09:04, Magnus Hagander wrote:
> On Thu, Jul 23, 2009 at 08:04, Tsutomu Yamada wrote:
>> Hello,
>>
>> Thank you for correcting patch.
>> However, I think the following block have to use VirualFree*Ex*().
>>
>> (yes, this should never happen, maybe there is actually no problem
Robert Haas 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 "Subquery Scan ss" will now
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
On Fri, Jul 24, 2009 at 8:07 PM, Magnus Hagander 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 the potential speedu
On Wed, Jul 22, 2009 at 8:57 AM, Magnus Hagander wrote:
> On Wed, Jul 22, 2009 at 14:53, Tom Lane wrote:
>> Magnus Hagander writes:
Yup, you would need a protocol change that would allow the client to
change its mind about what the username was after it got the auth
challenge. And
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 Fri, Jul 24, 2009 at 2:05 PM, Tom Lane wrote:
> Merlin Moncure 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 not proposing to change the
--On Freitag, Juli 24, 2009 11:38:06 -0400 Tom Lane
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 :( The customer
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 matc
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 reas
On Jul 24, 2009, at 11:10, 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.
Yes, that's precisely what I was trying to
On Jul 24, 2009, at 3:17, Brendan Jurd 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 (pgsql-hackers@postgresql.org)
Jeff Davis 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 FROM
correctly
Merlin Moncure 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 mailing list (pgsql-
Jeremy Kerr 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 methods to
On Fri, Jul 24, 2009 at 1:35 PM, Merlin Moncure wrote:
> On Fri, Jul 24, 2009 at 5:15 AM, David E. Wheeler 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
On Fri, Jul 24, 2009 at 5:15 AM, David E. Wheeler 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 NULL
>> or N
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:
http://www.postgresq
Sam Mason 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 to Codd (and I te
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
>> 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
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
On Fri, Jul 24, 2009 at 09:31:13AM -0400, Tom Lane wrote:
> Brendan Jurd 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 t
On Fri, Jul 24, 2009 at 11:15 AM, Tom Lane wrote:
> Robert Haas 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 state
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:
http://www.
On Fri, 2009-07-24 at 09:31 -0400, Tom Lane wrote:
> Brendan Jurd 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
> a row all of
Bernd Helmle 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
--
Sent via pg
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 wrote:
> mahendra chavan wrote:
> > What I meant by de-correla
Robert Haas 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 appropriate timestamp
Robert Haas 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 appropriate timesta
On Fri, Jul 24, 2009 at 10:47 AM, Kevin
Grittner wrote:
> daveg 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'
daveg 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. Possibly
Tom Lane wrote:
I wrote:
Andrew Dunstan 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 loo
I wrote:
> Andrew Dunstan 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'
mahendra chavan 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
> S_NAME
>
Joshua Tolley 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, NULL) isn't
On Fri, Jul 24, 2009 at 7:53 AM, Alex Brasetvik 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 that the
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):
> Th
Andrew Dunstan 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 surely nonrandom
Brendan Jurd 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 of the diffe
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 f
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
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 hav
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 is
2009/7/24 David E. Wheeler :
> 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.
"SELECT 1 IS NULL"
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
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
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 pote
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 in
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
To: Robert Haas
Cc:
On Fri, Jul 24, 2009 at 04:12, Jaime
Casanova wrote:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas wrote:
>> Here's my first attempt at setting client_encoding automatically from
>> locale.
>>
>
> Sorry for the many mails on this issue.. i will do a recolect of my findings:
>
> 1) it intr
2009/7/24 Tom Lane :
> 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 to WindowAgg's
96 matches
Mail list logo
