The following bug has been logged online:
Bug reference: 4940
Logged by: Robert Treat
Email address: xzi...@users.sourceforge.net
PostgreSQL version: 8.3.7
Operating system: Linux 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008
x86_64 x86_64 x86_64 GNU/Linux
Description:
On Fri, Jul 24, 2009 at 6:02 AM, Tom Lane wrote:
> I think the only thing we could do about it is downgrade the implicit
> casts to "name", which seems like a cure worse than the disease ---
> it'd interfere with searches in the system catalogs.
We could try to avoid user-visible functions like cu
Itagaki Takahiro writes:
> The result might be a designed behavior, but is very surprising.
> What should we care for it?
I think the only thing we could do about it is downgrade the implicit
casts to "name", which seems like a cure worse than the disease ---
it'd interfere with searches in the s
"limaozeng" wrote:
> select * from t where str in (user, 'abc...ijk');
> str
> ---
> mzli
> abc...xyz
> (2 rows)
>
> only 'mzli' ought to be appeared in the result list.
Your query is interpreted as
select * from t::name whe
The following bug has been logged online:
Bug reference: 4939
Logged by: limaozeng
Email address: limaoz...@163.com
PostgreSQL version: 8.4.0
Operating system: linux-32 bit
Description:error query result
Details:
create table t(str char(200));
insert into t values '
On Thu, Jul 23, 2009 at 21:15, Anders Edstrom wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4938
> Logged by: Anders Edstrom
> Email address: a...@yahoo.com
> PostgreSQL version: 8.3
> Operating system: Windows Vista
> Description: upgrade to 8.
The following bug has been logged online:
Bug reference: 4938
Logged by: Anders Edstrom
Email address: a...@yahoo.com
PostgreSQL version: 8.3
Operating system: Windows Vista
Description:upgrade to 8.4 issue
Details:
Hi,
When I run the installation of postgresql 8.4
Benjamin Reed writes:
> Attached is a test case, including the query that causes the error at
> the end. On 8.3, it returns 1 row (192.168.1.1), on 8.4 including the
> git 8.4 branch, it returns none.
Thanks for the test case. This patch should fix it.
regards, tom lane
"Mathieu Dupuis" writes:
> Here are the result of the simplest query that recreate the problem, as you
> can see the p.id and sod.performance_id are the same because I join on those
> fields but if I compare with one, I have a different result that if I
> compare the other.
These queries are pret
The following bug has been logged online:
Bug reference: 4936
Logged by: Mathieu Dupuis
Email address: mdup...@premieresloges.ca
PostgreSQL version: 8.4.0
Operating system: Ubuntu
Description:Bad result for SQL query
Details:
I have found a probleme with a sql query
"Frank Spies" writes:
> After finding out that bug #4918 was already fixed in 8.4 release, I played
> around with the interval input syntax in 8.4 and found that
> '2.5' year
> is not the same as
> '2.5 year'
> in release 8.4:
I don't think this is a bug. The former case specifies (per SQL
sta
The following bug has been logged online:
Bug reference: 4935
Logged by: Frank Spies
Email address: frank.sp...@biotronik.com
PostgreSQL version: 8.4
Operating system: Linux
Description:Weird input syntax for intervals, part 2
Details:
After finding out that bug #49
Hello!
I posted you a message about slowness of creation users more than 500 000
(#4919). It seems there is no workaround of this problem because of using
pg_auth flat file.
To override this problem is it possible to use LDAP authentification metod
to identify each user and speed up system?
13 matches
Mail list logo
