--- Martin Pelikan <[EMAIL PROTECTED]> escreveu:
> I think it's a bug because of security - nosey people are
> everywhere...
No. It's a feature.
> And I want not to other people see how many users and databases are
> here -
> server is half-public :)
>
See is one thing, access is another thing. W
Yes, I finally found the reference in pg_type.
Thanks for your help!
Regards,
Dirk
Tom Lane wrote:
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
I have now deleted every temp table I know from pg_temp_nnn using your
approach but still can't dump the schema:
pg_dump: schema
"Yuriy Vostrikoff" <[EMAIL PROTECTED]> writes:
> EXECUTE return wrong result after ALTER TABLE ALTER COLUMN TYPE. Is this
> expected behavior?
The prepared plan really should be invalidated by the ALTER, but we
don't currently have any infrastructure that would allow that to happen.
I think Neil C
"Pierre Beyssac" <[EMAIL PROTECTED]> writes:
> Description:lock freeing problem in transaction (?)
This seems to be already fixed by this patch:
http://archives.postgresql.org/pgsql-committers/2005-11/msg00235.php
regards, tom lane
---(end
The following bug has been logged online:
Bug reference: 2078
Logged by: Pierre Beyssac
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: FreeBSD 4.11
Description:lock freeing problem in transaction (?)
Details:
The following code causes t
The following bug has been logged online:
Bug reference: 2077
Logged by: Martin Pelikan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.4
Operating system: Gentoo Linux 2.6.14-gentoo-r2
Description:Hiding databases which I am not owner
Details:
We have had
Hi Tom,
The "zichtbaar" as false is indeed a very rare case and appearantly
isn't occuring right now. There are indeed 46631 rows in total, and all
46631 have the "zichtbaar" as true. Which reminds me to adjust the index
anyway ;-)
It appears to be happening if the fraction of zichtbaar's is
The following bug has been logged online:
Bug reference: 2079
Logged by: Yuriy Vostrikoff
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: Debian sarge
Description:strage PREPARE/EXECUTE behavior
Details:
EXECUTE return wrong result after
"Arjen" <[EMAIL PROTECTED]> writes:
> So, it uses the correct index, but somehow decides to also use the other
> cat2_... index, which it doesn't need of course.
I've tweaked the heuristics in choose_bitmap_and to (hopefully) work a
bit better in scenarios like this. Thanks for the example.
"Janko Richter" <[EMAIL PROTECTED]> writes:
> Partitioning does not work with PREPARE.
Well, no. How would you expect the prepared plan to know which
partition to look in, for a key value it doesn't have yet?
regards, tom lane
---(end of broadcast
The following bug has been logged online:
Bug reference: 2080
Logged by: Janko Richter
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Linux
Description:Partitioning does not work with PREPARE
Details:
Partitioning does not work with PREPA
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
> I have now deleted every temp table I know from pg_temp_nnn using your
> approach but still can't dump the schema:
> pg_dump: schema with OID 559701082 does not exist
> I could'nt find any reference to 559701082 in pg_class, pg_names
-- Forwarded message --From: Muhamamd Irfan Azam <[EMAIL PROTECTED]>Date: Nov 30, 2005 2:48 PM
Subject: LibPQ Error.To: pgsql-hackers@postgresql.org
Hi,
I have built the libpq from $Postgres/src/interfaces/libpq on the windows plateform for 8.1.0. To build i had to comment a funct
Hi Tom,
I have now deleted every temp table I know from pg_temp_nnn using your
approach but still can't dump the schema:
pg_dump: schema with OID 559701082 does not exist
I could'nt find any reference to 559701082 in pg_class, pg_namespace
or pg_proc.
Regards,
Dirk
Tom Lane wrote:
=?I
14 matches
Mail list logo
