Prev: libpq PGresult object and encoding
Next: [HACKERS] getting to beta
From: Pavel Stehule on 21 Feb 2010 05:00
Hello,

* Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope
so I understand SQL/PSM well so I am able to write production quality
implementation. If you like, I can integrate it to core. It can share
about 40-50% code with plpgpsm. The behave of plpgpsm is same as
plpgsql - without some plpgsql's historical issues (about FOUND, about
NULL and record type). SQL/PSM is litlle bit richer language. Now we
have not any wide used runtime so I don't thinking about rewriting.
Maybe we can rewrite these PL language for parrot or lua runtime in
future. But this step isn't necessary - people hasn't performance
problems with PL based on PL runtime.

* Month ago there was discussion about integration sprintf function to
core. I don't think it is good idea. sprintf implementation isn't
simple. I prefer more simple "format" function based on RAISE NOTICE
.... behave and code. It is significantly shorter and simpler. But for
people who like sprintf we can prepare some contrib module with basic
string functions - sprintf, left, right, reverse. This module can be
based on cleaned pstcollection -
http://pgfoundry.org/frs/download.php/2556/pstcoll-100127.tar.gz.

* Last two months I spent some time with preparing workshops about SQL
injection. PostgreSQL has only one issue related to this topic. It
allows multi queries. With this feature any successful injection can
have much more destructive impact. Now we have a GUC per user. I know,
we cannot break multiqueries without breaking basic functionality. But
we can break multiple queries on top level for some selected users -
(web application roles). Then we are able to configure database for
"secure web access". >>It isn't protection against SQL injection<<.
But it can down up possible risk about successful SQL injection. +
downgrade rights on system tables for web application roles.

* I would to like solve problem with fulltext reported by Czech users.
I will try implement preloaded TSearch dictionaries.

* Still I thinking about GROUPING SETS feature.

Regards
Pavel Stehule

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: libpq PGresult object and encoding
Next: [HACKERS] getting to beta