From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Joel Jacobson <joel(at)trustly(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL 1.2 |
Date: | 2014-09-04 16:22:36 |
Message-ID: | CAFj8pRCB0FOkFiy9u=qSmS5kOUZ1zgu4qFdAQPFiH5e6gcbcmw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-09-04 18:02 GMT+02:00 Kevin Grittner <kgrittn(at)ymail(dot)com>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> > 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.
Regards
Pavel
>
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-04 16:52:14 | Re: PQputCopyEnd doesn't adhere to its API contract |
Previous Message | Robert Haas | 2014-09-04 16:20:15 | Re: B-Tree support function number 3 (strxfrm() optimization) |