On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> 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
