Where can I found this path?
03.10.2012 18:55, Alvaro Herrera пишет:
Excerpts from wheelly's message of mar oct 02 05:49:27 -0300 2012:
Where is a bug in PostgreSQL or in documentation?
I think it was a bug in the code. I have committed a patch that should
fix this problem.
--
Sent via
The following bug has been logged on the website:
Bug reference: 6330
Logged by: Nikolay Gorshkov
Email address: nikolay.gorsh...@gmail.com
PostgreSQL version: 9.0.4
Operating system: Ubuntu 10.04.2 LTS
Description:
How to reproduce:
# create table test (uid
The following bug has been logged online:
Bug reference: 5214
Logged by: Nikolay
Email address: whee...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Gentoo Linux
Description:Permission troubles for views
Details:
There is two users in database: user_a and
To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
--
Sincerely yours,
Nikolay Samokhvalov
Postgresmen LLC, http://postgresmen.ru
ok, sorry, I've realized that it's yet another example of "outer
reference", Tom will say "read any SQL book" again :-)
http://archives.postgresql.org/pgsql-bugs/2006-12/msg00115.php
On 12/19/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
Followin
dified limit 10)
Is it a bug? If no, maybe to produce warning in such cases?
--
Best regards,
Nikolay
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
8/8/06, Jim Nasby <[EMAIL PROTECTED]> wrote:
More of a gotcha than a bug... basically, your select rule is hitting
the sequence again. I think there's a section in the rules chapter
that talks about this. GeneralBits might also have info.
Probably a better question is, what are you tryi
I still think that this is quite strange behaviour. When I write
'...SELECT NEW.id...' I don't expect that another calling of column's
default expr will take place. I just want to have access to "id"
column of just-created row.
Any thoughts?
-- Forwarded me
On 8/2/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
Does Postgres work this way? In the case of 'delete from tbl;' we
have search condition>=TRUE for all rows. If we evaluate it *before*
any other operation, we should mark all rows to be deleted. I guess,
Postgres
t - he reports, that problem remains
even after dropping FK at all.
On 8/2/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> Is this a bug or not?
I don't think so --- or perhaps better, this is a buggy trigger.
he UPDATE i
id, parent) values(4, 3);
--only 1/2 of the records are deleted!
DELETE FROM recursive;
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
--
Best regards,
Nikolay
---(end of broadcast
The following bug has been logged online:
Bug reference: 2490
Logged by: Nikolay Samokhvalov
Email address: [EMAIL PROTECTED]
PostgreSQL version: CVS
Operating system: fedora core 5
Description:'||' and type casting for user defined types
Details:
Assu
The following bug has been logged online:
Bug reference: 2245
Logged by: Nikolay Samokhvalov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Linux Fedora Core 4
Description:pg_dump doesn't dump expressions with sequence in
DEFAULT se
esses
DEBUG: all server processes terminated; reinitializing shared memory
and semaphores
Then I copied the data directory to my machine and continued there.
The log entries from my original message actually should start here.
Please excuse me.
Best regards,
Nikolay Hristov
[EMAIL PROT
14 matches
Mail list logo
