Re: Extension Templates S03E11
От | Tom Lane |
---|---|
Тема | Re: Extension Templates S03E11 |
Дата | |
Msg-id | 444.1387323771@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Extension Templates S03E11 (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Extension Templates S03E11
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > On 17 December 2013 18:32, Stephen Frost <sfrost@snowman.net> wrote: >> I have no idea where you're going with this, but I *do* object to >> sticking an SQL script which defines a bunch of objects into a catalog >> table *right next to where they are properly defined*. There's just no >> sense in it that I can see, except that it happens to mimic what we do >> today- to no particular purpose. > The purpose is clear: so it is part of the database backup. It's a > fairly boring purpose, not fancy at all. But it is a purpose, indeed > *the* purpose. The point Stephen is making is that it's just as easy, and far more reliable, to dump the package-or-whatever-you-call-it by dumping the definitions of the contained objects, as to dump it by dumping the text blob it was originally created from. So I don't see a lot of merit to claiming that we need to keep the text blob for this purpose. We did it differently for extensions in part because you can't dump a .so as a SQL command, so dump-the-contained-objects wasn't going to be a complete backup strategy in any case. But for a package containing only SQL objects, that's not a problem. > We aim to have the simplest implementation that meets the stated need > and reasonable extrapolations of that. Text in a catalog table is the > simplest implementation. That is not a reason to reject it, especially > when we aren't suggesting a viable alternative. The first part of this assertion is debatable, and the claim that no viable alternative has been suggested is outright wrong. regards, tom lane
В списке pgsql-hackers по дате отправления: