search

EndPointCorp / end-point-blog

End Point Dev blog
https://www.endpointdev.com/blog/
17 stars 65 forks source link

Comments for pgcrypto pg_cipher_exists errors on upgrade from PostgreSQL 8.1 #317

Open phinjensen opened 6 years ago

phinjensen commented 6 years ago

Comments for https://www.endpointdev.com/blog/2010/06/pgcrypto-pgcipherexists-errors-on/ By Greg Sabino Mullane

To enter a comment:

  1. Log in to GitHub
  2. Leave a comment on this issue.
phinjensen commented 6 years ago 
original author: Anonymous
date: 2010-06-11T11:00:13-04:00

Can't you just dump in custom format, generate the dump list, remove the lines you don't want and import that?

phinjensen commented 6 years ago 
original author: Jon Jensen
date: 2010-06-11T12:48:36-04:00

Certainly you could do that. That's what I would have done myself.

But I think Greg makes a good case that it's nice to have the old functions defined but throwing a meaningful error, rather than just not working and making it appear that pgcrypto isn't installed, or isn't installed correctly.

In other words, I think Greg's solution here is about helping users of the system after the import, not just fixing the import itself.

phinjensen commented 6 years ago 
original author: Greg Sabino Mullane
date: 2010-06-11T13:02:17-04:00

Anon: In addition to Jon's reasoning (which is quite correct: I hate the fact that the functions simply disappeared), I prefer my way because I was running the dump often and on different databases, so that would have been a lot of extra steps to do each time compared with pg_dump --clean mydb | psql

phinjensen commented 6 years ago 
original author: Robert Treat
date: 2010-06-12T17:46:09-04:00

This is why I have been advocating putting contrib modules in their own schemas for years. In most cases, it's much simpler to exclude the contrib modules on the dump, and install the new version of contrib module before upgrading.

phinjensen commented 6 years ago 
original author: Greg Sabino Mullane
date: 2010-06-14T10:33:49-04:00

Robert: Yes, that would be nice, but I'm not holding my breath on that one. For the final iteration, I will probably export the schema only, run uninstall plus install for each contrib module, and then install the data. What's annoying is some contrib modules do not have uninstall SQL in older versions!