Thread: Data Migration
Howdy, This sounds simple yet i haven't found a way to do this except thru perl scripts.... I have two databases, crossover and crbak crossover is the production database and crbak is the development database. I have unique tables in crossover i want to migrate over to crbak. Can this be done thru SQL? something like Insert in crbak.function select * from crossover.function; I/m not sure of the syntax here.... Thanks, -Rob ************
Robert Hiltibidal <rob@y2k.state.il.us> writes:
> I have unique tables in crossover i want to migrate over to crbak. Can this
> be done thru SQL?
No; in Postgres, different databases are different universes ... and
there are no wormholes in SQL ;-).
Use pg_dump with -t to dump out the table(s) you want from the one
database, and then load the resulting script into the other.
regards, tom lane
************
Tom Lane wrote: > > Robert Hiltibidal <rob@y2k.state.il.us> writes: > > I have unique tables in crossover i want to migrate over to crbak. Can this > > be done thru SQL? > > No; in Postgres, different databases are different universes ... and > there are no wormholes in SQL ;-). > > Use pg_dump with -t to dump out the table(s) you want from the one > database, and then load the resulting script into the other. You can do it in one shot like this: pg_dump -t unique_table crossover | psql crbak ------------------- Hannu
On Wed, 1 Dec 1999, Tom Lane wrote: > No; in Postgres, different databases are different universes ... and > there are no wormholes in SQL ;-). Does SQL92 say no wormholes? Is it a major pain to code this? I've got no complaints as I can see ways to do it from the application level. Are there any thoughts/plans on providing cross database/instance connectivity? I can see a use (can't we all) where a mostly read-only set of tables with fewer accesses sets on a lightly loaded server. Or the personel department (erh... human resources) has a database that the shipping department needs some information from for POC at the company's Anytown facility. Rod -- Roderick A. Anderson raanders@altoplanos.net Altoplanos Information Systems, Inc. Voice: 208.765.6149 212 S. 11th Street, Suite 5 FAX: 208.664.5299 Coeur d'Alene, ID 83814 ************
Thus spake Roderick A. Anderson
> On Wed, 1 Dec 1999, Tom Lane wrote:
> > No; in Postgres, different databases are different universes ... and
> > there are no wormholes in SQL ;-).
>
> Does SQL92 say no wormholes? Is it a major pain to code this? I've got
> no complaints as I can see ways to do it from the application level.
I don't know what SQL92 says and. like you, I have easy ways to do this
at the app level but for what it's worth, here's a suggested syntax
for this in case someone want to implement it.
OPEN DATABASE <dbname> [AS <alias>] [HOST host] [PORT port] [TYPE <db type>]
And use it as
OPEN DATABASE db1 HOST 'other.what.com';
SELECT * FROM mytab, db1.othertab yourtab WHERE mytab.f1 = yourtab.f1;
or
SELECT mytab.f1, db1.yourtab.f2, ...
The TYPE attribute allows for opening other databases such as Oracle, etc.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
************
On Wed, 1 Dec 1999, D'Arcy J.M. Cain wrote:
> Date: Wed, 1 Dec 1999 16:23:29 -0500 (EST)
> From: "D'Arcy J.M. Cain" <darcy@druid.net>
> To: "Roderick A. Anderson" <raanders@altoplanos.net>
> Cc: tgl@sss.pgh.pa.us, rob@y2k.state.il.us,
> pgsql-interfaces@postgreSQL.org
> Subject: Re: [INTERFACES] Data Migration
>
> Thus spake Roderick A. Anderson
> > On Wed, 1 Dec 1999, Tom Lane wrote:
> > > No; in Postgres, different databases are different universes ... and
> > > there are no wormholes in SQL ;-).
> >
> > Does SQL92 say no wormholes? Is it a major pain to code this? I've got
> > no complaints as I can see ways to do it from the application level.
>
> I don't know what SQL92 says and. like you, I have easy ways to do this
> at the app level but for what it's worth, here's a suggested syntax
Yes, currently we do this at application level, but as pointed out
in previous posts, in web application with using persistence connection
between httpd and db backend it's very important to have support
at db level !
> for this in case someone want to implement it.
>
> OPEN DATABASE <dbname> [AS <alias>] [HOST host] [PORT port] [TYPE <db type>]
>
> And use it as
>
> OPEN DATABASE db1 HOST 'other.what.com';
> SELECT * FROM mytab, db1.othertab yourtab
> WHERE mytab.f1 = yourtab.f1;
>
> or
>
> SELECT mytab.f1, db1.yourtab.f2, ...
>
> The TYPE attribute allows for opening other databases such as Oracle, etc.
That would be really cool, especially in web applications.
Implementation of this feature would be a great win if postgres could
works with several databases **through one connection**.
I think for security reason OPEN DATABASE should contain user info.
Regards,
Oleg
>
> --
> D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
> http://www.druid.net/darcy/ | and a sheep voting on
> +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
>
> ************
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
************
On Wed, Dec 01, 1999 at 04:23:29PM -0500, D'Arcy J.M. Cain wrote: > Thus spake Roderick A. Anderson > > On Wed, 1 Dec 1999, Tom Lane wrote: > > > No; in Postgres, different databases are different universes ... and > > > there are no wormholes in SQL ;-). > > > > Does SQL92 say no wormholes? Is it a major pain to code this? I've got > > no complaints as I can see ways to do it from the application level. > > I don't know what SQL92 says and. like you, I have easy ways to do this > at the app level but for what it's worth, here's a suggested syntax > for this in case someone want to implement it. > > OPEN DATABASE <dbname> [AS <alias>] [HOST host] [PORT port] [TYPE <db type>] This syntax seems reasonable, although as Oleg pointed out, you need various amounts of authentication info. I suppose an inital restriction (and latter default) for connecting to dbs under the same postmaster, is to use the same user, since you've already authenticated. Going to a differnent type of db would require some alternative authentication, however. There may be db type specific attributes as well. > > And use it as > > OPEN DATABASE db1 HOST 'other.what.com'; > SELECT * FROM mytab, db1.othertab yourtab > WHERE mytab.f1 = yourtab.f1; > > or > > SELECT mytab.f1, db1.yourtab.f2, ... > This notation, db.table.field, does seem to be how other DBMSs do it. I've been wondering, however, if our parser would have any trouble with it, since in an identifier string token1.token2, token1 is no longer guaranteed to be a table. Need to look at the code, I suppose. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005 ************
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> This notation, db.table.field, does seem to be how other DBMSs do
> it. I've been wondering, however, if our parser would have any trouble
> with it, since in an identifier string token1.token2, token1 is no longer
> guaranteed to be a table.
The parser would indeed get confused, since multiple dots is an old and
still-supported PostQUEL notation for some sort of function invocation
(can't say that I fully understand it). I suppose we could rip that out
without drawing too many complaints. However, parser problems would be
the least of the worries in supporting multiple-database access within a
single backend. We're talking about a major project here, and I'm not
seeing value in it proportional to the work required. If you don't want
to have multiple backend connections open in a client, why not refactor
your database layout so that all the stuff you need is in one database?
regards, tom lane
************
Thus spake Roderick A. Anderson
> On Wed, 1 Dec 1999, Tom Lane wrote:
> > No; in Postgres, different databases are different universes ... and
> > there are no wormholes in SQL ;-).
>
> Does SQL92 say no wormholes? Is it a major pain to code this? I've got
> no complaints as I can see ways to do it from the application level.
I don't know what SQL92 says and. like you, I have easy ways to do this
at the app level but for what it's worth, here's a suggested syntax
for this in case someone want to implement it.
OPEN DATABASE <dbname> [AS <alias>] [HOST host] [PORT port] [TYPE <db type>]
And use it as
OPEN DATABASE db1 HOST 'other.what.com';
SELECT * FROM mytab, db1.othertab yourtab WHERE mytab.f1 = yourtab.f1;
or
SELECT mytab.f1, db1.yourtab.f2, ...
The TYPE attribute allows for opening other databases such as Oracle, etc.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
************
On Wed, Dec 01, 1999 at 04:23:29PM -0500, D'Arcy J.M. Cain wrote: > Thus spake Roderick A. Anderson > > On Wed, 1 Dec 1999, Tom Lane wrote: > > > No; in Postgres, different databases are different universes ... and > > > there are no wormholes in SQL ;-). > > > > Does SQL92 say no wormholes? Is it a major pain to code this? I've got > > no complaints as I can see ways to do it from the application level. > > I don't know what SQL92 says and. like you, I have easy ways to do this > at the app level but for what it's worth, here's a suggested syntax > for this in case someone want to implement it. > > OPEN DATABASE <dbname> [AS <alias>] [HOST host] [PORT port] [TYPE <db type>] This syntax seems reasonable, although as Oleg pointed out, you need various amounts of authentication info. I suppose an inital restriction (and latter default) for connecting to dbs under the same postmaster, is to use the same user, since you've already authenticated. Going to a differnent type of db would require some alternative authentication, however. There may be db type specific attributes as well. > > And use it as > > OPEN DATABASE db1 HOST 'other.what.com'; > SELECT * FROM mytab, db1.othertab yourtab > WHERE mytab.f1 = yourtab.f1; > > or > > SELECT mytab.f1, db1.yourtab.f2, ... > This notation, db.table.field, does seem to be how other DBMSs do it. I've been wondering, however, if our parser would have any trouble with it, since in an identifier string token1.token2, token1 is no longer guaranteed to be a table. Need to look at the code, I suppose. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005 ************
Robert Hiltibidal <rob@y2k.state.il.us> writes:
> I have unique tables in crossover i want to migrate over to crbak. Can this
> be done thru SQL?
No; in Postgres, different databases are different universes ... and
there are no wormholes in SQL ;-).
Use pg_dump with -t to dump out the table(s) you want from the one
database, and then load the resulting script into the other.
regards, tom lane
************
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> This notation, db.table.field, does seem to be how other DBMSs do
> it. I've been wondering, however, if our parser would have any trouble
> with it, since in an identifier string token1.token2, token1 is no longer
> guaranteed to be a table.
The parser would indeed get confused, since multiple dots is an old and
still-supported PostQUEL notation for some sort of function invocation
(can't say that I fully understand it). I suppose we could rip that out
without drawing too many complaints. However, parser problems would be
the least of the worries in supporting multiple-database access within a
single backend. We're talking about a major project here, and I'm not
seeing value in it proportional to the work required. If you don't want
to have multiple backend connections open in a client, why not refactor
your database layout so that all the stuff you need is in one database?
regards, tom lane
************
On Wed, 1 Dec 1999, Tom Lane wrote: > No; in Postgres, different databases are different universes ... and > there are no wormholes in SQL ;-). Does SQL92 say no wormholes? Is it a major pain to code this? I've got no complaints as I can see ways to do it from the application level. Are there any thoughts/plans on providing cross database/instance connectivity? I can see a use (can't we all) where a mostly read-only set of tables with fewer accesses sets on a lightly loaded server. Or the personel department (erh... human resources) has a database that the shipping department needs some information from for POC at the company's Anytown facility. Rod -- Roderick A. Anderson raanders@altoplanos.net Altoplanos Information Systems, Inc. Voice: 208.765.6149 212 S. 11th Street, Suite 5 FAX: 208.664.5299 Coeur d'Alene, ID 83814 ************
On Wed, 1 Dec 1999, D'Arcy J.M. Cain wrote:
> Date: Wed, 1 Dec 1999 16:23:29 -0500 (EST)
> From: "D'Arcy J.M. Cain" <darcy@druid.net>
> To: "Roderick A. Anderson" <raanders@altoplanos.net>
> Cc: tgl@sss.pgh.pa.us, rob@y2k.state.il.us,
> pgsql-interfaces@postgreSQL.org
> Subject: Re: [INTERFACES] Data Migration
>
> Thus spake Roderick A. Anderson
> > On Wed, 1 Dec 1999, Tom Lane wrote:
> > > No; in Postgres, different databases are different universes ... and
> > > there are no wormholes in SQL ;-).
> >
> > Does SQL92 say no wormholes? Is it a major pain to code this? I've got
> > no complaints as I can see ways to do it from the application level.
>
> I don't know what SQL92 says and. like you, I have easy ways to do this
> at the app level but for what it's worth, here's a suggested syntax
Yes, currently we do this at application level, but as pointed out
in previous posts, in web application with using persistence connection
between httpd and db backend it's very important to have support
at db level !
> for this in case someone want to implement it.
>
> OPEN DATABASE <dbname> [AS <alias>] [HOST host] [PORT port] [TYPE <db type>]
>
> And use it as
>
> OPEN DATABASE db1 HOST 'other.what.com';
> SELECT * FROM mytab, db1.othertab yourtab
> WHERE mytab.f1 = yourtab.f1;
>
> or
>
> SELECT mytab.f1, db1.yourtab.f2, ...
>
> The TYPE attribute allows for opening other databases such as Oracle, etc.
That would be really cool, especially in web applications.
Implementation of this feature would be a great win if postgres could
works with several databases **through one connection**.
I think for security reason OPEN DATABASE should contain user info.
Regards,
Oleg
>
> --
> D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
> http://www.druid.net/darcy/ | and a sheep voting on
> +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
>
> ************
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
************