The following bug has been logged online:
Bug reference: 5228
Logged by: aftab
Email address: akha...@hotmail.co.uk
PostgreSQL version: 8.3.8
Operating system: Centos 5
Description:Execution of prepared query is slow when timestamp
parameter is used
Details:
e.g.
p
Tom Lane wrote:
> Heikki Linnakangas writes:
>> The logical next step would be to get rid of the interXact concept
>> altogether and always associate temporary files with the current
>> resource owner; the caller should switch to a sufficiently long-lived
>> one before calling.
>
> That would mea
The following bug has been logged online:
Bug reference: 5230
Logged by: aftab
Email address: akha...@hotmail.co.uk
PostgreSQL version: 8.3.8
Operating system: Centos 5
Description:Limit operator slows down
Details:
S1="SELECT *
FROM position WHERE
position.POSITION
The following bug has been logged online:
Bug reference: 5229
Logged by: Fredrik Palm
Email address: fredrik.p...@humlab.umu.se
PostgreSQL version: 8.3 & 8,4
Operating system: Vista 64
Description:Queing requests when not using psql
Details:
I am using a standard de
2009/12/3 Fredrik Palm :
>
> The following bug has been logged online:
>
> Bug reference: 5229
> Logged by: Fredrik Palm
> Email address: fredrik.p...@humlab.umu.se
> PostgreSQL version: 8.3 & 8,4
> Operating system: Vista 64
> Description: Queing requests when not using
Tom Lane wrote:
> Sorry about that --- I had confused this case with that of a bare
> NULL literal, which Postgres treats the same as an unadorned
> string literal for type determination purposes. You're right that
> the spec treats them differently. This is feasible for the spec's
> purposes
"Wagner, Kurt" wrote:
> when writing a character constant elsewhere
> then at first it is interpreted as character constant - right?
> then it is casted to the desired type
No. It was confusing for me, too; but the PostgreSQL behavior is to
treat what the standard calls a as being
of type U
"Kevin Grittner" wrote:
> There is an understandable tendency of those who work deep in the
> guts of the PostgreSQL software, making all this custom type code
> work,
I mangled that sentence worse than usual. The tendency is to see
the PostgreSQL behavior as natural and to forget the expecta
On Thu, Dec 3, 2009 at 7:07 AM, aftab wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5230
> Logged by: aftab
> Email address: akha...@hotmail.co.uk
> PostgreSQL version: 8.3.8
> Operating system: Centos 5
> Description: Limit operator slows down
Heikki Linnakangas writes:
> Ok, committed that way. I made the cross-check a WARNING. That seems
> like the right level of seriousness, although I see that many of the
> other similar checks are Asserts.
Looks good. I'm a bit tempted to rename the interXact argument to
something like noOwner --
The following bug has been logged online:
Bug reference: 5231
Logged by: Thomas Hamilton
Email address: thomashamilto...@yahoo.com
PostgreSQL version: 8.3.8
Operating system: Ubuntu 4.2.4
Description:SELECT DISTINCT poorly implemented vs SELECT ... GROUP
BY
Details:
On Thu, Dec 03, 2009 at 03:56:05PM +, Thomas Hamilton wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5231
> Logged by: Thomas Hamilton
> Email address: thomashamilto...@yahoo.com
> PostgreSQL version: 8.3.8
> Operating system: Ubuntu 4.2.4
> Descr
Thomas Hamilton wrote:
> When run against a large dataset with a small number of distinct results
> HashAggregate is an order of magnitude more efficient!
>
> Since the spec does not require DISTINCT to return sorted results, I don't
> believe Sort ... Unique will ever be more efficient than Hash
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Ok, committed that way. I made the cross-check a WARNING. That seems
>> like the right level of seriousness, although I see that many of the
>> other similar checks are Asserts.
>
> Looks good. I'm a bit tempted to rename the interXact argument to
The following bug has been logged online:
Bug reference: 5232
Logged by: David Gardner
Email address: dgard...@creatureshop.com
PostgreSQL version: 8.4.1
Operating system: Debian, amd64
Description:plpythonu s=s.op() raises an exception
Details:
If I create the foll
Hi!
Thank you very much for your input, especially since I now found the problem
in my PHP-software.
We are using session to cache results from previous queries in order to more
quickly feed the client with data.
However, using sessions also seems to stop the PHP-software from having more
than one
"David Gardner" writes:
> CREATE OR REPLACE FUNCTION pyreplace(src text,s text)
> RETURNS text AS
> $BODY$
> try:
> src=src.replace(s,'')
> return src
> except Exception,e:
> return str(e)
> $BODY$
> LANGUAGE 'plpythonu' VOLATILE
> COST 100;
Weird. You seem to need both the try
Not sure about the try block being related, I included it in my example
mostly because the example is a simplified version of some code I was
working on that had a try/except block.
I tried the function without the try block and it raised the same
exception (just uncaught):
CREATE OR REPLACE F
On tor, 2009-12-03 at 14:46 -0800, David Gardner wrote:
> Not sure about the try block being related, I included it in my
> example mostly because the example is a simplified version of some
> code I was working on that had a try/except block.
> I tried the function without the try block and it ra
Peter Eisentraut writes:
> ... So you should not try to assign to
> the parameters of a function.
If it's allowed in normal Python functions, that definitely needs to be
documented. Better would be to fix it or at least throw a more
intelligible error ...
regards, tom la
On Thu, Dec 3, 2009 at 10:45 AM, aftab khan wrote:
> This is not exactly the same what I posted yesterday, What I have posted
> today also include EXPLAIN ANALYZE OUTPUT .
[ adding the list back to the CC line ]
It looks like you have a problem very similar to one Laurence Laborde
was complainin
The following bug has been logged online:
Bug reference: 5233
Logged by: Fred Wei
Email address: w...@niwa.co.nz
PostgreSQL version: 8.1.11
Operating system: SUSE Linux Enterprise Server 10 SP2 (x86_64)
Description:delete wrong doing with subquery where condition
Deta
On Thu, Dec 3, 2009 at 8:21 PM, Fred Wei wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5233
> Logged by: Fred Wei
> Email address: w...@niwa.co.nz
> PostgreSQL version: 8.1.11
> Operating system: SUSE Linux Enterprise Server 10 SP2 (x86_64)
> Descript
On Fri, Nov 27, 2009 at 8:09 AM, Martin wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5217
> Logged by: Martin
> Email address: searepo...@aol.at
> PostgreSQL version: 8.4.1
> Operating system: M$ Vista (but does not matter) same on XP, ...
> Descript
Fred Wei wrote:
> cod_old=# delete from tmp where k in (select k from tmp2);
> DELETE 1
> --this is wrong, because k does not exist in tmp2!
That behavior is correct, k is referring to tmp.k. See
http://archives.postgresql.org/message-id/200910160726.n9g7qeeg097...@wwwmaster.postgresql.org
This s
25 matches
Mail list logo
