Re: RFD: PostgreSQL Schema Support - Mailing list pgadmin-hackers

Option 2 is certainly the best long term.  A couple of releases from
now and very few people will be using 7.2 or prior -- and they should
expect newer tools to be broken .

Support namespaces in the cleanest way possible, and potentially add a
temporary hack (for the length of 7.3.x releases and maybe part of
7.4) to support 7.2 and prior with a 'pg_public' or default namespace.
ie.  Pretend a namespace exists for public stuff, as when they upgrade
to 7.3 that would be where it all ends up (I think), so it's somwhat
appropriate.

--
Rod Taylor

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.

----- Original Message -----
From: "Dave Page" <dpage@vale-housing.co.uk>
To: <pgadmin-hackers@postgresql.org>
Sent: Friday, April 05, 2002 7:40 AM
Subject: [pgadmin-hackers] RFD: PostgreSQL Schema Support


> I'm currently starting to implement support for some of the more
desirable
> features of PostgreSQL 7.3 which is now well in development. One of
these
> areas (which are all now on the ToDo list incidently) is Schema
support.
> There are a number of ways we could implement this, and I'd like to
get some
> feedback on what people think is right.
>
> Note; Schemas will probably end up being called Namespaces in
pgSchema
> because of the obvious naming conflict (that's what Tom Lane's been
calling
> the related catalogues and columns in PostgreSQL itself).
>
> 1) The most basic design.
>      - Add Namespaces & pgNamespace classes under pgDatabase.
>      - Add a Namespace property to all objects that can live in a
Namespace.
>      - Allow selection of a Namespace when creating objects.
>
>    Pros:
>      - Relatively simple & easy to implement.
>
>    Cons:
>      - Very 'bolted on' design.
>
> 2) The middle of the road approach.
>      - Add Namespaces & pgNamespace classes under pgDatabase.
>      - *Move* classes such as Tables & Sequences etc. from
pgDatabase to
> pgNamespace.
>      - Add a ctx.CurrentNamespace property to clsContext in pgAdmin.
>
>    Pros:
>      - The object hierarchy will be correct.
>
>    Cons:
>      - Lose backward compatibility with PostgreSQL < 7.3.
>
> 3) The whole shebang.
>      - Add Namespaces & pgNamespace classes under pgDatabase.
>      - *Copy* classes such as Tables & Sequences etc. from
pgDatabase to
> pgNamespace.
>      - Add a ctx.CurrentNamespace property to clsContext in pgAdmin.
>      - Recode pgAdmin to use the current object hierarchy with
PostgreSQL <
> 7.3, otherwise the new.
>
>    Pros:
>      - Backwards compatibility is maintained.
>      - The object hierarchy will be correct.
>
>    Cons:
>      - The code will be *very* complex, and probably
incomprehensible to
> most developers.
>      -  By far the most amount of work.
>
> Comments and other suggestions would definitely be well received
with this
> one :-)
>
> Regards, Dave.
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
majordomo@postgresql.org
>