Re: Re: Outstanding patches

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I do not like Ian Taylor's plpgsql cursor patch; trying to do cursors
> inside plpgsql with no SPI-level support is too much of a kluge. We
> should first add cursor support to SPI, then fix plpgsql. Much of the
> parsing work he's done could be salvaged, but the implementation can't
> be. (And I don't want to apply it now and back it out later --- it adds
> too many warts.)

I think most of the cursor patch will stand even after SPI-level
support for cursors is added. But it's up to you, of course. 7.2 is
a long way away in any case. I would be happy to rework the patch
when SPI supports cursors.

> We need to discuss whether we like the %TYPE feature proposed by Ian
> Taylor. It seems awfully nonstandard to me, and I'm not sure that the
> value is great enough to be worth inventing a nonstandard feature.

Oracle PL/SQL supports this, and PL/SQL code that I've seen uses it
extensively. PL/pgSQL supports %TYPE in all places a type may be
used, except parameter and return types.

> ISTM that people don't normally tie functions to tables so tightly that
> it's better to define a function in terms of "the type of column foo
> of table bar" than just in terms of the type itself. Ian claims that
> this is helpful, but is it really likely that you can change that column
> type without making *any* other mods to the function?

Sure. I've seen code in which all access to the database is done via
stored procedures. It's natural to write that sort of code using
%TYPE. Otherwise any change you make to the schema, you have to make
two or three times.

Admittedly, this may apply mostly to what Postgres calls type
modifiers. But it's still a natural way to write the procedure. Why
duplicate information?

> Moreover, in
> exchange for this possible benefit you are opening yourself to breaking
> the function if you choose to rename either the column or the table.

If you do that you've most likely broken the function anyhow, since
you probably wouldn't use %TYPE if you weren't referring to the
column. Anyhow, if you don't use %TYPE you can break the function in
the other way, by changing the type of the column. So I think it's
six of one, half-dozen of the other.

> (If we do like the
> functionality, then the patch itself seems OK with the exception of the
> gram.y definition of func_type; the table name should be TokenId not
> just IDENT.)

I think I tried that, and I think it led to lots of reduce/reduce
errors. But maybe that was only in 7.0.3.

The problem that the function type does not change when the schema
changes is problematical. I would have been happier if I could have
left the %TYPE as a string to be interpreted at execution time. But
of course that does not work with the current system for function
overloading.

Ian

---------------------------(end of broadcast)---------------------------
TIP 483: In Lowes Crossroads, Delaware, it is a violation of local law
for any pilot or passenger to carry an ice cream cone in their pocket
while either flying or waiting to board a plane.