From: | Ian Lance Taylor <ian(at)airs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Outstanding patches |
Date: | 2001-05-09 01:02:17 |
Message-ID: | siy9s7l4h2.fsf@daffy.airs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-05-09 01:23:05 | Re: [HACKERS] MULTIBYTE and SQL_ASCII (was Re: Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?) |
Previous Message | Bruce Momjian | 2001-05-08 22:43:45 | Re: Re: Outstanding patches |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-05-09 01:23:05 | Re: [HACKERS] MULTIBYTE and SQL_ASCII (was Re: Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?) |
Previous Message | Larry Mulcahy | 2001-05-08 23:34:30 | Is DataSource implemented? |