On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > "Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> writes: >> So we're conceding that this is a valid need and people will now have >> a way to meet it. Is the argument against having CINE syntax that it >> would be more prone to error than the above, or that the code would be >> so large and complex as to create a maintenance burden? > > The argument against CINE is that it's unsafe. The fragment proposed > by Andrew is no safer, of course, but it could be made safe by adding > additional checks that the properties of the existing object are what > the script expects. So in principle that's an acceptable approach, > whereas CINE will never be safe. Well, there can be methods extrinsic to the system for controlling this sort of thing. For example, I can provide a script, using CINE, that will either install version 2 of my app into some database or that will upgrade an existing version 1 installation to version 2. It's true that if someone has taken the version-1 schema and made manual modifications to it, then things might blow up. But, I can tell people that they shouldn't do that, or the upgrade script might break. If they do and it does then they get to keep both pieces. Even if I do the whole thing in PL/pgsql, I'm still not going to check for every stupid thing someone might have done to break the schema... I think the cat is already out of the bag on this one, and it's just a matter of whether we're willing to provide some convenient syntax or leave people to hand-code it. > But actually I thought we had more or less concluded that CREATE OR > REPLACE LANGUAGE would be acceptable (perhaps only if it's given > without any extra args?). I'm not sure there's any value in that restriction - seems more confusing than helpful. > Or for that matter there seems to be enough > opinion on the side of just installing plpgsql by default. CINE is > a markedly inferior alternative to either of those. For languages, yes. ...Robert -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
