Re: Re: Outstanding patches - Mailing list pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.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.