pl/python quoting functions

2011/1/11 Jan Urbański <wulczer@wulczer.org>:

Here's a patch that adds a few PL/Python functions for quoting strings.
It's an incremental patch on top of the plpython-refactor patch sent in
http://archives.postgresql.org/message-id/4D135170.3080705@wulczer.org.

Git branch for this patch:
https://github.com/wulczer/postgres/tree/functions

The new functions are plpy.quote_literal, plpy.quote_nullable and
plpy.quote_ident, and work just like their sql or plperl equivalents.

I reviewed this.

The patch applies and compiles cleanly and all the tests are passed.
The patch adds 3 functions which works as the corresponding SQL
functions. The test is enough, without any additional docs. No
feature/performance issues found.

I mark this "Reader for Committer".

Regards,

--
Hitoshi Harada

On 04/02/11 18:10, Hitoshi Harada wrote:

2011/1/11 Jan Urbański <wulczer@wulczer.org>:

Here's a patch that adds a few PL/Python functions for quoting strings.
It's an incremental patch on top of the plpython-refactor patch sent in
http://archives.postgresql.org/message-id/4D135170.3080705@wulczer.org.

Git branch for this patch:
https://github.com/wulczer/postgres/tree/functions

The new functions are plpy.quote_literal, plpy.quote_nullable and
plpy.quote_ident, and work just like their sql or plperl equivalents.

I reviewed this.

The patch applies and compiles cleanly and all the tests are passed.
The patch adds 3 functions which works as the corresponding SQL
functions. The test is enough, without any additional docs. No
feature/performance issues found.

I mark this "Reader for Committer".

Thanks!

I guess a short paragraph in the Utility Functions section of the
PL/Python docs would be in order, I'll try to add it today.

Jan

On 06/02/11 10:54, Jan Urbański wrote:

On 04/02/11 18:10, Hitoshi Harada wrote:

2011/1/11 Jan Urbański <wulczer@wulczer.org>:

Here's a patch that adds a few PL/Python functions for quoting strings.
It's an incremental patch on top of the plpython-refactor patch sent in
http://archives.postgresql.org/message-id/4D135170.3080705@wulczer.org.

Git branch for this patch:
https://github.com/wulczer/postgres/tree/functions

The new functions are plpy.quote_literal, plpy.quote_nullable and
plpy.quote_ident, and work just like their sql or plperl equivalents.

I reviewed this.

The patch applies and compiles cleanly and all the tests are passed.
The patch adds 3 functions which works as the corresponding SQL
functions. The test is enough, without any additional docs. No
feature/performance issues found.

I mark this "Reader for Committer".

Thanks!

I guess a short paragraph in the Utility Functions section of the
PL/Python docs would be in order, I'll try to add it today.

Added docs and merged with master.

Committed this, with two changes: Changed some things around with the
way const char * is propagated. Just casting it away is not nice. Also
dropped the error tests in the _quote.sql regression test. This
generates three different wordings of error messages from Python with
2.6, 3.1, and 3.2, which I don't care to maintain. Maybe one day we'll
have a better solution for this.

On 22/02/11 22:48, Peter Eisentraut wrote:

Committed this, with two changes: Changed some things around with the
way const char * is propagated. Just casting it away is not nice. Also
dropped the error tests in the _quote.sql regression test. This
generates three different wordings of error messages from Python with
2.6, 3.1, and 3.2, which I don't care to maintain. Maybe one day we'll
have a better solution for this.

Thanks.

One thing: you removed the conditional pfree from PLy_quote_ident, which
makes this function leak memory if the actual quoting took place, no? Is
that leak too small to worry about?

Cheers,
Jan

On ons, 2011-02-23 at 11:26 +0100, Jan Urbański wrote:

One thing: you removed the conditional pfree from PLy_quote_ident,
which makes this function leak memory if the actual quoting took
place, no? Is that leak too small to worry about?

Many functions in PostgreSQL leak memory in this way. It's not worth
worrying about, and certainly not worth violating a called function's
API for it.