Re: sepgsql contrib module

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: KaiGai Kohei <kaigai@ak.jp.nec.com>

Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>, PgHacker <pgsql-hackers@postgresql.org>

Date: 2011-01-20T04:01:27Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

pgindent run for 9.0, second run
- 239d769e7e05 9.0.0 cited

2011/1/19 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>>  And how about adding a
>> ProcessUtility_hook to trap evil non-DML statements that some
>> nefarious user might issues?
>>
> It seems to me reasonable as long as the number of controlled command
> are limited. For example, LOAD command may be a candidate being
> controlled without exceptions.
> However, it will be a tough work, if the plug-in tries to parse and
> analyze supplied utility commands by itself.

I think the key is to either accept or reject the command based on
very simple criteria - decide based only on the command type, and
ignore its parameters.

> I uploaded my draft here.
>  http://wiki.postgresql.org/wiki/SEPostgreSQL_Documentation
>
> If reasonable, I'll move them into *.sgml style.

I have yet to review that, but will try to get to it before too much
more time goes by.

> I may want to simplify the step to installation using an installer
> script.

OK, but let's get this nailed down as soon as possible.  Tempus fugit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company