elein wrote: > On Mon, Jan 15, 2007 at 10:13:16AM -0500, Andrew Dunstan wrote: >> >> >> Neil Conway wrote: >> >On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote: >> > >> >>I don't think they need to be integrated any time soon, but if we were >> >>to design pg_dump and pg_dumpall from scratch, it seems more logical >> to >> >>use a single program >> >> >> > >> >On thinking about this some more, it might be useful to factor much of >> >pg_dump's logic for reconstructing the state of a database into a >> shared >> >library. This would make it relatively easy for developers to plug new >> >archive formats into the library (in addition to the present 3 archive >> >formats), or to make use of this functionality in other applications >> >that want to reconstruct the logical state of a database from the >> >content of the system catalogs. We could then provide a client app >> >implemented on top of the library that would provide similar >> >functionality to pg_dump. >> > >> >Moving pg_dump's functionality into the backend has been suggested in >> >the past (and rejected for good reason), but I think this might be a >> >more practical method for making the pg_dump logic more easily >> reusable. >> > >> > >> > >> >> I like this idea. For example, we might usefully map some of this to >> psql \ commands, without having to replicate the underlying logic. > > Don't we already do this with the .psqlrc file? >
No. \ commands are implemented in C code. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match