Re: Programmatically duplicating a schema
От | Adrian Klaver |
---|---|
Тема | Re: Programmatically duplicating a schema |
Дата | |
Msg-id | 324d62a5-76c9-0745-f878-a0a1dc142483@aklaver.com обсуждение исходный текст |
Ответ на | Re: Programmatically duplicating a schema (matt.figg@internode.on.net) |
Список | pgsql-general |
On 03/12/2018 11:05 PM, matt.figg@internode.on.net wrote: > Thanks Adrian, > > Really appreciate the suggestions. > > The objective when trying to solve this for the Apartment library itself > is to keep it generic (works for any/all database objects - tables, > views, stored procedures, 3rd party extension objects, etc.) & to > require minimal configuration (preferably not having to tell the library > your schema). > > I believe pg_dump was the only way to satisfy the second point. The > reason we'd want to infer the create statements via pg_dump is, so we > don't need to keep database migration files in sync with a 'create new > schema' SQL script. It adds risk that they get out of sync, causing > inconsistencies in new schemas created by the library. Seems to me your best hope is to make a plea on --hackers for a flag that turns off schema qualification of object names. > > Assuming there's no other way to infer the create statements from the > public schema, Ruby on Rails' structure.sql could probably be used as a > starting point for the 'create new schema' SQL file. It's similar > already, however it's also generated via pg_dump (having the same issues > as Apartment library). > http://guides.rubyonrails.org/v3.2.9/migrations.html#types-of-schema-dumps > This is outside the realms of this mail group though. > > Cheers, > > Matt. > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: