Re: Outstanding patches - Mailing list pgsql-hackers

> Okay, I looked through these ...

Thanks.

> 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 know Jan is talking about SPI support fpr plpgsql.  I will keep the
patch but not apply it.

> Fernando Nasser's ANALYZE patch is superseded by already-applied work,
> though if he wants to do the promised test additions I would be happy.

I have already emailed him to say you did it already.  Removed.

> The PAM support patch concerns me --- it looks like yet another chunk
> of code that will tie up the postmaster in a single-threaded
> conversation with a remote daemon that may or may not respond promptly.
> I recommend holding off on this until we think about whether we
> shouldn't restructure the postmaster to do all authentication work in
> per-client subprocesses.

I have not idea what PAM is.  If it is a valuable feature, we can
install it.  But if it is yet another authentication scheme, it could
add more confusion to our already complicated setup.  Seems you are
saying it is the latter, which is fine with me.


> 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.
> 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?  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.
> The potential net gain seems really small.  (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 thought it was valuable.  I know in Informix 4gl you can set variables
to track column types, and it helps, especially when you make a column
longer or something. It also better documents the variable.  I remember
someone else stating this was a nice feature, so I am inclinded to apply
it, with your suggested changes.

> I did not look at any of the JDBC or libpq++ patches.  The other stuff
> seemed OK on a first glance.

Ditto.  JDBC will need comment from JDBC people.  The libpq++ stuff
looks pretty good to me.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026