On Mon, Sep 28, 2009 at 2:51 AM, Yaming Gu wrote:
>
> Thank you so much for your kind reply.
> Your analysis sounds very reasonable. I checked my Perl version, it is "Perl
> 5.8.9 Build 826" which is the latest version in the series of 5.8.*.
> The whole process of installation of Perl goes well
"Bernt Marius Johnsen" writes:
> Description:Query gives different number of rows depending on ORDER
> BY
The attached patch should fix this.
regards, tom lane
Index: src/backend/optimizer/README
===
> "Tom" == Tom Lane writes:
Tom> I'm inclined to think that the best solution is to have
Tom> process_equivalence just reject any clauses that have equal()
Tom> left and right sides, ie, throw them back to be processed as
Tom> ordinary non-equivalence clauses.
>> Hmm. Is it ever possibl
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I'm inclined to think that the best solution is to have
> Tom> process_equivalence just reject any clauses that have equal()
> Tom> left and right sides, ie, throw them back to be processed as
> Tom> ordinary non-equivalence clauses.
>
> "Tom" == Tom Lane writes:
Tom> After digging into it, I find that:
Tom> 1. Without ORDER BY, process_equivalence generates an
Tom> equivalence class that lists k twice. This is pretty bogus but
Tom> it happens to produce the desired results in the example at
Tom> hand. (In some othe
On Tue, Sep 22, 2009 at 10:13:24AM -0400, Tom Lane wrote:
>
> Another point that comes to mind is shared_preload_libraries: if plperl
> is loaded once in the postmaster, it seems entirely likely that the same
> END block would be executed in multiple backends after having been
> loaded only once.
Tom Lane writes:
> Andrew Gierth writes:
>> Notice that the (k = k) qual is being dropped somewhere, which changes
>> the output since that's a disguised not-null condition.
> Huh ... I'm surprised it only does that with the ORDER BY present.
> I suppose it's got something to do with the equival
Andrew Gierth writes:
> Notice that the (k = k) qual is being dropped somewhere, which changes
> the output since that's a disguised not-null condition.
Huh ... I'm surprised it only does that with the ORDER BY present.
I suppose it's got something to do with the equivalence-class machinery.
> Bernt Marius Johnsen wrote:
>> Dump of the database:
To save anyone else the bother, there's a VASTLY simpler testcase for
this one, requiring no tables at all:
test1=# explain select * from (values (1),(null)) v(k) where k = k order by k;
QUERY PLAN
Heikki Linnakangas wrote (2009-09-28 18:10:07):
> Bernt Marius Johnsen wrote:
> > Dump of the database:
Attached.
>
> It looks like the dump got word-wrapped somewhere along the way. Could
> you gzip it and post it again, please?
>
> --
> Heikki Linnakangas
> EnterpriseDB ht
I wrote:
> Hmm ... it would be expected in the case of a timestamp, but seems
> wrong when the input is interval.
... although actually the documentation defines HH as "hour of day (01-12)"
so it seems that this is per docs; at least, if you wanted to have
intervals behave differently from timesta
On Mon, Sep 28, 2009 at 10:12 AM, Jacques Caron wrote:
> Hi,
>
> You can use a trigger before insert and a pl/pgsql function that goes:
>
> BEGIN
> UPDATE table SET ... WHERE pk=NEW.pk
> IF FOUND THEN
> RETURN NULL;
> ELSE
> RETURN NEW;
> END IF;
> END;
>
> Jacques.
That seems about right.
Dave Page writes:
> This was posted as a documentation comment:
> to_char(interval '0d 0h 12m 44s', 'DD HH MI SS');
> with HH and HH12 will return 12 instead of 0.
> Testing on 8.4.1, it does seem to be the case that you get "00 12 12
> 44". Seems bogus to me, but am I and the OP missing somethin
Bernt Marius Johnsen wrote:
> Dump of the database:
It looks like the dump got word-wrapped somewhere along the way. Could
you gzip it and post it again, please?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
Hi,
You can use a trigger before insert and a pl/pgsql function that goes:
BEGIN
UPDATE table SET ... WHERE pk=NEW.pk
IF FOUND THEN
RETURN NULL;
ELSE
RETURN NEW;
END IF;
END;
Jacques.
At 19:36 27/09/2009, Robert Haas wrote:
Sometimes when I've needed to do this I've written a PL/pgsql
--On 27. September 2009 14:36:45 -0400 Robert Haas
wrote:
On Sun, Sep 27, 2009 at 11:36 AM, Tom Lane wrote:
Robert Haas writes:
On Sat, Sep 26, 2009 at 12:35 PM, Tom Lane wrote:
Well, yeah. That's exactly how it's documented to work: an ON INSERT
rule is executed after the INSERT pro
The following bug has been logged online:
Bug reference: 5084
Logged by: Bernt Marius Johnsen
Email address: bernt.john...@sun.com
PostgreSQL version: 8.3.7
Operating system: Linux 2.6.24-23-generic
Description:Query gives different number of rows depending on ORDER
B
Thank you so much for your kind reply.
Your analysis sounds very reasonable. I checked my Perl version, it is "Perl
5.8.9 Build 826" which is the latest version in the series of 5.8.*.
The whole process of installation of Perl goes well without any something
wrong. And I can run Perl command ou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Sep 27, 2009 at 11:11:05PM -0500, Jaime Casanova wrote:
> On Sun, Sep 27, 2009 at 9:45 PM, Robert Haas wrote:
> >
> > (with apologies to anyone on this mailing list who ACTUALLY speaks
> > Spanish - it must have hurt to read that)
> >
>
> act
This was posted as a documentation comment:
to_char(interval '0d 0h 12m 44s', 'DD HH MI SS');
with HH and HH12 will return 12 instead of 0.
Testing on 8.4.1, it does seem to be the case that you get "00 12 12
44". Seems bogus to me, but am I and the OP missing something?
--
Dave Page
Enterprise
20 matches
Mail list logo
