Re: Patch: plan invalidation vs stored procedures
От | Dimitri Fontaine |
---|---|
Тема | Re: Patch: plan invalidation vs stored procedures |
Дата | |
Msg-id | 3DE62AEC-7E2E-48C7-82CF-ABDC62A31434@hi-media.com обсуждение исходный текст |
Ответ на | Re: Patch: plan invalidation vs stored procedures ("Robert Haas" <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Le 19 août 08 à 22:03, Robert Haas a écrit : > All database-driven applications have this problem. Any time you have > a database on the backend and interface code on the front-end, you > need to keep in mind that it won't necessarily be possible to update > the two of them simultaneously, especially if you have multiple > back-ends and multiple front-ends, as you almost certainly do. Even > if PostgreSQL invalidated plans in the particular situation you're > discussing, there would still be other problems. You could add a new, > non-NULLable column to a table before updating the code that insert > into that table, or drop an old column that the code still counts on > being able to access. Using functions the way Skype uses them means not issuing a single insert, update or delete directly from your code, but calling a function which takes care about it. So you use PostgreSQL transactionnal DDL to roll-out new function versions at the same time you push the schema modifications, and commit it all in one go. > Maybe in your particular environment plan invalidation for functions > will solve most of the cases you care about When the code only is a client to an SQL functions API, which effectively replaces SQL as the way to interact between code and database, then I believe plan invalidation at function change is the missing piece. > , but I respectfully submit > that there's no substitute for good release engineering. If you don't > know exactly what functions are going to be created, modified, or > dropped on your production servers during each release before you > actually roll that release out... you probably need to improve your > internal documentation. Agreed :) - -- dim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkirK2kACgkQlBXRlnbh1bmxvQCgmowpfnZ5nFRml0mNfj2HRE+3 HJEAnR3G6Lhnb7R4+iSze8xGACwyk4D7 =of1o -----END PGP SIGNATURE-----
В списке pgsql-hackers по дате отправления: