The following bug has been logged on the website:
Bug reference: 6495
Logged by: Lou Duchez
Email address: l...@paprikash.com
PostgreSQL version: 9.1.2
Operating system: Fedora 16, CentOS 5
Description:
Download the following file and feed it into psql:
http://www.pa
Hello
2012/2/28 :
> The following bug has been logged on the website:
>
> Bug reference: 6495
> Logged by: Lou Duchez
> Email address: l...@paprikash.com
> PostgreSQL version: 9.1.2
> Operating system: Fedora 16, CentOS 5
> Description:
>
> Download the following file and fee
On Sat, Feb 25, 2012 at 15:23, wrote:
> This works:
> alter table t1 add x float not null;
> This doesn't work:
> alter table t1 add x float not null default 0;
> It fails with ERROR: cannot alter table "t1" because column "t2.j" uses its
> row type
> But I would expect second alter to pass and
Hi,
After upgrading pgadmin3 fro 1.14.1 to 1.14.2 via yum, the link in /usr/bin
went missing.
The link was originally installed by the previous pgadmin3 install from yum.
The restored link looks like this:
lrwxrwxrwx 1 root root 27 Feb 28 11:08 /usr/bin/pgadmin3_91 ->
/usr/pgsql-9.1/bin/pgad
Hi,
(Got your private mail, too)
I will try to push updates soon. Sorry about that.
Regards,
Devrim
On Tue, 2012-02-28 at 19:53 +0100, r d wrote:
> Hi,
>
> After upgrading pgadmin3 fro 1.14.1 to 1.14.2 via yum, the link in /usr/bin
> went missing.
> The link was originally installed by the p
The following bug has been logged on the website:
Bug reference: 6497
Logged by: Ryan Lowe
Email address: rl...@pablowe.net
PostgreSQL version: 9.1.3
Operating system: Linux
Description:
There is an edge case where Postgres will return an error to the client, but
comm
The following bug has been logged on the website:
Bug reference: 6496
Logged by: Luciano Barcellos
Email address: luci...@geocontrol.com.br
PostgreSQL version: 8.4.8
Operating system: Debian Squeeze (2.6.32-5-amd64)
Description:
-- Create and populate table
CREATE TAB
rl...@pablowe.net writes:
> There is an edge case where Postgres will return an error to the client, but
> commit the operation anyway, thus breaking the contract with the client:
> postgres=# begin; insert into s.t (c) values (1);
> affected)>
> postgres=# commit;
>
>
> The data is now on both
luci...@geocontrol.com.br writes:
> -- Wrong SQL. Reports no syntax error but yields unexpected data
> SELECT s."name" FROM (SELECT DISTINCT SUBSTRING(bug."name" FROM 1 FOR 3)
> FROM public.is_this_a_bug bug) s;
This is not a bug, exactly, although I'll agree that it's surprising
behavior. What i
On 28.2.2012. 15:01, Marti Raudsepp wrote:
> On Sat, Feb 25, 2012 at 15:23, wrote:
>> This works:
>> alter table t1 add x float not null;
> Peeking at the code, currently any modifications that cause a rewrite
> of the original table are disallowed.
>
> Adding a nullable column without a default
Tom Lane wrote:
> rl...@pablowe.net writes:
>> There is an edge case where Postgres will return an error to the
>> client, but commit the operation anyway, thus breaking the
>> contract with the client:
>
>> postgres=# begin; insert into s.t (c) values (1);
>> > not affected)>
>> postgres=# commi
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Huh? If the backend dumped core before you sent it the commit,
>> the data will certainly not be committed. It might be physically
>> present on disk, but it won't be considered valid.
> I suppose that there is a window of time between the commit
12 matches
Mail list logo
