Skip to content

Conversation

@msakrejda
Copy link
Contributor

User can define their own types in Postgres, and if those types do not depend on any tables or transitive dependencies of tables in the system, a pliny db:reset will not drop them.

This pull request adds code to drop them, borrowing the SQL from psql's \dT.

I'm sure there are other cleanup tasks we're missing (one that comes to mind immediately is functions--if you lean on me, I can probably add that), but this should be useful on its own.

Maciek Sakrejda added 2 commits April 13, 2015 20:02
We need the semantics of #all here since we'll run other SQL on the
connection in the block.
@pedro
Copy link

pedro commented Apr 15, 2015

Dang, my initial reaction was analogue to #147: wish there's a cleaner/more generic way to do this.

I see rake db:create runs CREATE DATABASE internally with Postgres, so shouldn't db:reset just drop/recreate it? Is the only issue here that this might not work with hosted dbs like Heroku's? Can you think of any other workaround?

@msakrejda
Copy link
Contributor Author

@pedro you're right: db:reset won't work with a database like Heroku's, but maybe that's not a big deal? It's certainly a lot simpler, and heroku has its own pg:reset. I usually use db:reset locally, so I'd be fine with reset basically being drop and create, but that's basically just db:setup, right?

I do think db:nuke is kind of broken as is, though, and fixing it correctly will involve running a bunch of different catalog queries (looking briefly through the different things users can create, we have tables, UDFs, UDAs, UDTs, sequences which are not part or serial primary keys, domains, extensions, and possibly more).

Maybe it should just be dropped entirely? Or become an alias for db:drop?

@msakrejda msakrejda mentioned this pull request Apr 16, 2015
8 tasks
@pedro
Copy link

pedro commented Jun 1, 2015

I'd +1 for removing nuke, unless we're willing to work on all these subtle factors.
@brandur thoughts?

@brandur
Copy link
Member

brandur commented Jun 1, 2015

@pedro @uhoh-itsmaciek +1 for removing it completely. It was a good idea, but it feels a lot more simple and safer to just remove a database and add it back. This of course will have its own problems in certain situations, but hopefully its a fairly rarely initiated action.

@pedro
Copy link

pedro commented Jun 2, 2015

Cool, replacing by #169.

@uhoh-itsmaciek thank you!

@pedro pedro closed this Jun 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants