Re: Return type of triger functions from OPAQUE to TRIGGER in 7.3

On Tue, Feb 25, 2003 at 04:10:14PM -0500, Tom Lane wrote:
>
> Actually, there were at least half a dozen distinguishable meanings of
> "OPAQUE" in older releases :-(. The failure to make these distinctions
> led to such infamous security holes as the "select cash_out(2)" bug.
> I don't think there's any real speed gain involved ... but not having
> the backend dump core when you pass something the wrong kind of argument
> is a big improvement IMHO.

Ok, I see. Makes sense now. I was trying to understand the rationale for
the change, and you explained it well.

> >> I would classify this as a bug, because it defeats the purpose of CREATE
> >> OR REPLACE, at least for triggers. If the behavior of CREATE FUNCTION is to
> >> change OPAQUE to TRIGGER, then CREATE OR REPLACE FUNCTION should be
> >> consistent with that behavior.
>
> But that *isn't* the behavior of CREATE FUNCTION. There are some hacks
> (temporary ones, I hope) in CREATE TRIGGER and other places to adjust
> the type of an existing function rather than declaring error. We
> intended those hacks only to serve to let existing pre-7.3 pg_dump scripts
> be loaded into 7.3; not as an indefinite equivalencing of OPAQUE with
> other types, because that would defeat the purpose of introducing the
> other types to begin with.

Ok.

> What you're essentially suggesting is that "CREATE OR REPLACE FUNCTION
> foo() RETURNS OPAQUE" shouldn't fail if it finds an existing function
> returning trigger --- nor, presumably, any of the several other
> pseudotypes that replaced OPAQUE. We could do that, I suppose, but it
> strikes me as opening a big hole for the same kinds of mistakes that we
> are trying to prevent. Who's to say whether the function definition
> you're supplying is actually meant as a trigger, or a language handler,
> or the other possibilities?

No, that was not what I was suggesting. I was suggesting (based on my
assumption that 'create function ... returns opaque' would convert the
return type to trigger), that its behaviour be made consistent with
'create or replace function' and throw an error if the type is opaque.

> It's hard to believe that this is the only thing standing between you
> and having SQL code that works in both 7.2 and 7.3. That would mean
> that you have no intention of adopting *any* 7.3 improvements. Is that
> really your plan?

For our next release, our plan was to have both 7.2 and 7.3
compatibility. For the release after that, 7.2 compatibility would
probably be dumped in favor of 7.3, where we could make use of 7.3-specific
features. We wanted it to be a gradual path.

-Roberto

--
+----| Roberto Mello - http://www.brasileiro.net/ |------+
+ Computer Science Graduate Student, Utah State University +
+ USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ +
OS/2, Windows/0