Andrew Kohlsmith wrote:
> > > Is there a particular reason why plain text is forced?
> > Because pg_dumpall is producing a script file.
> > This is obviously not optimal, but it's not very clear how to do better.
>
> Agreed. :-)
>
> I notice that pg_dumpall just uses a query to grab a list of d
> > Or is that on the TODO for whenever foreign keys can be across databases?
> I very seriously doubt that PG will *ever* support foreign keys across
> databases.
No problem. I'm not that advanced of a user or admin to want it, I was just
trying to peer into the crystal ball and try to anticip
> > Is there a particular reason why plain text is forced?
> Because pg_dumpall is producing a script file.
> This is obviously not optimal, but it's not very clear how to do better.
Agreed. :-)
I notice that pg_dumpall just uses a query to grab a list of databases and
some information about t
grant wrote:
> You could fake some of this (select only) by using the dblink stuff in
> contrib. You could link back to yourself and make it work. Maybe if
> you REALLY need it, you could modify dblink to allow updates as well as
> selects. If you really need it that bad, you have the sourc
You could fake some of this (select only) by using the dblink stuff in
contrib. You could link back to yourself and make it work. Maybe if
you REALLY need it, you could modify dblink to allow updates as well as
selects. If you really need it that bad, you have the source, write it.
--
Andrew Kohlsmith <[EMAIL PROTECTED]> writes:
> Is there a way to start a transaction at the start of
> the dump and hold it throughout successive connections, finally releasing it
> at the end?
No, and since one backend can only talk to one database, I don't foresee
that changing.
> Or is that
Andrew Kohlsmith <[EMAIL PROTECTED]> writes:
> Is there a particular reason why plain text is forced?
Because pg_dumpall is producing a script file.
This is obviously not optimal, but it's not very clear how to do better.
regards, tom lane
---(en
