The following bug has been logged online:
Bug reference: 4677
Logged by: aiwaniuk
Email address: aiwan...@instytut.com.pl
PostgreSQL version: >8.0
Operating system: linux
Description:memory growth
Details:
i postgres version 8.2, 8.3 and probobly 8.1 there is proble
"aiwaniuk" writes:
> i postgres version 8.2, 8.3 and probobly 8.1 there is problem with running
> VOLATILE plpgsql function with begin - exception checking that performs
> other VOLATILE plpgsql function. if either, first or second performing
> removed, problem doesn't shows. here's an example
Hello
I have a customer who bought an IBM Power Systems, running AIX 5.3 and
wants to install the PostgresSQL 8.1.9. Can you pls tell me where I can
Download this version for AIX? and if youa have some documentation or FAQs
about the installation you can share?
I was looking on the following
Thank you in advance.
I realize only the superuser and table owner can change the ownership of a
table, but is there a way to modify the database owner privileges to do
the same?
Example:
userA is database owner and creates/owns 20 tables
superuser creates userB
superuser changes database owne
>>> wrote:
> We have a lot of test databases with multiple db_owners, but very few
> superusers, and table_owners switch all the time.
A quick, untested idea:
Create a table_owner role.
Create your users with NOINHERIT and GRANT table_owner to them as
appropriate.
REVOKE CREATE ON SCHEMA
All,
This is not so much a bug as a weird inconsistency, which ought to go on
a list somewhere so that it gets cleaned up the next time someone
overhauls pg_dump:
Summary: CREATE TYPE uses explicit schemas
Versions Tested: 8.2.9, 8.3.5
Platform: Linux
Description of Issue:
When doing pg_dump
On Thu, 2009-02-26 at 15:25 -0800, Josh Berkus wrote:
> That is, a custom type in a complex type declaration is explicitly
> schema-qualified, even when the schema in question is in the default
> schema_path. This is inconsistent with all other database objects,
> which use "SET search_path" to
Jeff,
Functions are similar, actually. The argument list needs to specify
schema paths as well, if it's not in some expected place (I think it
does so for all schemas other than pg_catalog).
Except that they don't appear to do so.
--Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgr
Manuel G Vazquez B/Mexico/IBM wrote:
Hello
I have a customer who bought an IBM Power Systems, running AIX 5.3 and
wants to install the PostgresSQL 8.1.9. Can you pls tell me where I
can Download this version for AIX? and if youa have some documentation
or FAQs about the installation you can
On Thu, 2009-02-26 at 15:52 -0800, Josh Berkus wrote:
> Jeff,
>
> > Functions are similar, actually. The argument list needs to specify
> > schema paths as well, if it's not in some expected place (I think it
> > does so for all schemas other than pg_catalog).
>
> Except that they don't appear to
Jeff,
In the general case though, for any object that refers to multiple other
objects, I don't see any way around explicit schema qualification. I
suppose it could be smart and say "foo_type is unique in my search path,
so I don't need to schema-qualify it".
Yeah, but for most other objects "
Josh Berkus writes:
> When doing pg_dump in text mode, complext types will be dumped like this:
> CREATE TYPE complex_foo (
> var INT,
> gar TEXT,
> natch public.foo_type
> );
You didn't say which schema "complex_foo" is in?
> That is, a custom type in a complex type
On Thu, 2009-02-26 at 21:42 -0800, Josh Berkus wrote:
> Jeff,
>
> > In the general case though, for any object that refers to multiple other
> > objects, I don't see any way around explicit schema qualification. I
> > suppose it could be smart and say "foo_type is unique in my search path,
> > so
Jeff Davis writes:
> It seems like pg_dump tries fairly hard to make the output readable in
> the typical case. It does seem a little inconsistent that the list of
> types that make up another type don't follow the exact same rules;
Are you entirely sure that they don't? Josh didn't provide enou
On Fri, 2009-02-27 at 01:24 -0500, Tom Lane wrote:
> Are you entirely sure that they don't?
Oh, you're right, of course:
postgres=# create type public.mytype as (i int);
CREATE TYPE
postgres=# create type public.mytype2 as (j mytype);
CREATE TYPE
-- pg_dump output:
CREATE TYPE mytype2 AS (
15 matches
Mail list logo
