Marko Tiikkaja <pgmail@joh.to> writes:
>> What happens if you have a table foo and another table "FoO"?
>
> They would go to the same file. If you think there are technical issues
> behind that decision (e.g. the dump would not restore), I would like to hear
> an example case.
I didn't try the patch itself yet so I wanted to hear that's something
you did actually try out, that's about it :) As soon as we're past the
initial agreement on this patch landing in (which I really want to see
happen), I'll devote some time on testing it.
> On the other hand, some people might find it preferrable to have them in
> different files (for example foo, foo.1, foo.2 etc). Or some might prefer
> some other naming scheme. One of the problems with this patch is exactly
> that people prefer different things, and providing switches for all of the
> different options people come up with would mean a lot of switches. :-(
I think this facility should provide something simple and useful, and
not something tasty. Database backups and exports are not meant to cater
with taste, they are meant to be easy to restore. In that very case, we
want to have a set of properly organized SQL files for doing partial
restores, right?
> It feels a bit icky to me too, but I didn't feel comfortable with putting in
> a lot of work to refactor the API because of how controversial this feature
> is.
+1
>> pg_dump | pg_restore
>> pg_export | psql
>
> While I agree that this idea - when implemented - would be nicer in
> practically every way, I'm not sure I want to volunteer to do all the
> necessary work.
What I think needs to happen now is a commiter's buy in that we want to
get there at some point and that your current patch is not painting us
into any corner now. So that we can accept it and have a documented path
forward.
Regards,
--
Dimitri Fontaine 06 63 07 10 78
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
