From: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "'Jean-Michel POURE'" <jmpoure(at)axitrad(dot)com>, pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: Packages, Repository and Rebuilding |
Date: | 2001-09-20 14:51:08 |
Message-ID: | 8568FC767B4AD311AC33006097BCD3D6338FB9@woody.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
> -----Original Message-----
> From: Jean-Michel POURE [mailto:jmpoure(at)axitrad(dot)com]
> Sent: 20 September 2001 15:39
> To: Dave Page
> Subject: RE: [pgadmin-hackers] Packages, Repository and Rebuilding
>
>
>
> >- Migration Wizard (currently banging my head against a brick wall).
> We need to be able to define local settings: numerical (comma
> or point
> delimiter) and date (dd/mm/yyyy or mm/dd/yyyy).
> Otherwise, importing does not work on French Windows systems.
Yes, the OO mode I'm designing should cope with these issues easily.
> >- Reverse Engineering Wizard (write full SQL scripts/publish
> databases
> >to other datasources).
> What is it exactly? Is it you want to parse batch SQL scripts
> from MySQL,
> Oracle and MsSQL?
No, basically it will dump the schema as an sql script from the selected
server or database. Alternatively, it will publish (==copy) the schema to
another specified database(s). Basically a mechanism for moving your schema
from a dev or staging server to one or more production servers.
> Why not extend pgSchema with the next version of VB
> (inheritance)? Database abstraction layers are usually built
> using inheritance.
Partly because I'm not convinced that the next version of VB is the way to
go yet. I've heard that it doesn't work on Win95 for example.
> >One thing that did cross my mind the other day - all that
> messing about
> >figuring out dependencies that we (mainly you) worked on was
> somewhat
> >unnecessary - just do everything in oid order and everything
> should be
> >OK!
> Interesting if it works. What about cross-dependencies (view
> has functions,
> functions have indexes, indexes might be dropped and
> recreated) ?
Functions don't have indexes. Anyway, as far as I can tell, this is how
pg_dump works. Until it is possible to really alter a view or function, the
oid will always denote the order in which objects were created, hence you
don't need a pg_dependancies table yet. Once you can edit objects, then such
a table *will* be required for pg_dump to work sensibly.
> Are oids primary keys at database level?
> PostgreSQL members have been
> discussing a lot about this rebuilding feature.
> I remember reading "We will not implement this feature before a real
> dependency table is built" on PostgreSQL hackers. Is this so simple?
Yes, oids are guaranteed unique (and sequential) so you can treat them as a
primary key quite safely.
> Have a nice beer.
Cheers /Dave.
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2001-09-20 15:00:07 | Re: Packages, Repository and Rebuilding |
Previous Message | Dave Page | 2001-09-20 13:53:12 | Re: Packages, Repository and Rebuilding |