> You just need a ISAM API for Postgres, That is all.
Joel sure hasn't *shown* us anything to suggest that wouldn't answer his needs better than any PL, or explained why that wouldn't be a better solution for him.
I understand what Joel does. And there is a space for improvement of plpgsql - on syntax level, on internal level. But we can start with some less controversial.
And some controversial points we can coverage by extensions. It is in conformance with Postgres community politics - where is not agreement, use extensions. We have to be able to write these extensions.
Extensibility of plpgsql is on the begin. But for some special use cases, these extensions can be perfect.
From this long discuss I am thinking so there is perfect agreement on plpgsql asserts. We needed. And now we know where assertations can be used. There is agreement on using binary casting instead IO casting every where where it is possible. And I am not against to ensuring consistent behave of assigning, returning from fce for composite types. There is small differences between rows, records, .. But should not be too hurry. There are only few people who would to changes in this area. Almost users are happy.
Personally I would to see a discussion about enhancing SPI much more -- because it is base of all PL and some performance limits and some internal complexity of plpgsql (and plpgsql_check too) is based on missing some interface between SPI and PL.
