Re: Implementing SQL/PSM for PG 8.2
От | Andrew Dunstan |
---|---|
Тема | Re: Implementing SQL/PSM for PG 8.2 |
Дата | |
Msg-id | 42BF139D.6090705@dunslane.net обсуждение исходный текст |
Ответ на | Implementing SQL/PSM for PG 8.2 ("Denis Lussier" <denis@enterprisedb.com>) |
Ответы |
Re: Implementing SQL/PSM for PG 8.2
|
Список | pgsql-hackers |
Is the intention here to make PSM a first class language (i.e. handled by the main dbengine scanner/parser) of just another PL? If the latter it seems far less worth doing. Doing this as a first class language, however, would be great, just great. As for pgfoundry, I think it's fair to say (from my various perspectives as a pgfoundry admin, owner of a PL project there, and general hacker) that experience is mixed on things that have close backend integration requirements. In particular, I would advise you to conduct pretty much all discussions abou the project on the -hackers list for a project like this. That way you avoid giving anyone surprises, and you will get the best and most wide-ranging advice and feedback. cheers andrew Denis Lussier wrote: >Hi All, > >My company (EnterpriseDB) is very interested in helping to make ANSI-ISO SQL Stored Procedures part of standard BSD Postgres. The SQL/PSM standard is currently used in DB2 and is being implemented in MySQL 5.0. Note that I'm NOT a bigfan of adding Oracle compatibility to PL/pgSQL, but, I'm biased in this regard because EnterpriseDB's SPL (Superset ProceduralLanguage) supports Redwood (pl/sql) and Redmond (transact-sql) style programming. > >For various technical and backward compatibility reasons, I don't think SQL/PSM should be a replacement for PL/pgSQL. AlthoughI do think it should heavily leverage the solid foundation afforded by the PL/pgSQL code base. I think it shouldstart as a separate project on PgFoundry. Once it is working and fully tested and rock solid and proven... I thinkit should then be considered to become part of the core & installed by default alongside plpgsql. > >Please note that this is all appropriate for 8.2, because changes to the server side code are necessary to support ANSIstored proc signatures and flexible out/inout parameter passing. EnterpriseDB will publish those suggested server changesfor review so that work can begin on plsqlpsm sooner rather than later. > >What do y'all think?? I believe the first step is for us to create "plsqlpsm" as a BSD project in PgFoundry. > >--Luss > > > >
В списке pgsql-hackers по дате отправления: