Tuesday, January 12, 2010

Procedural Languages in PostgreSQL 8.5: The One That Works!

While much of the PostgreSQL hacker world is abuzz over two-letter acronyms (HS, SR, VF), I will second Andrew's post and will generalize this to say, partially tooting my own horn, of course, that the next PostgreSQL release will be a great one for procedural languages. Behold:
  • PL/pgSQL is installed by default.
  • New DO statement allows ad hoc execution of PL code.
  • PL/pgSQL finally got a sane parser.
  • PL/Perl got a shot in the arm.
  • PL/Python got saner data type handling, Unicode support, and Py3k support.
  • Not directly related, but the coming PL/Proxy features are looking promising as well.
  • (Meanwhile, language historians will be interested to know that PL/Tcl has received exactly zero feature or bug-fix commits since 8.4.)
This will be a great boost for PostgreSQL the development platform.


  1. Wow, that's one pl/tcl feature for every user, except Jan!

  2. Don't forget named parameters for all PLs.

  3. Hey... I've had pl/tcl functions in most of our registries for *years* now... That was the only "regex-happy" pl/language that was easy to add in on AIX :-).

    Question from a relevant historian: How many feature/bug-fix commits has PL/Tcl *needed* since 8.4??? :-)

  4. PostgreSQL's easy extensibility is one of its greatest strengths.

    plperl functions are probably the only perl code I ever write ;) Plperl has been great for a long time, and I may add plpython to my reportoire after this release.