Robert Haas robertmh...@gmail.com wrote:
If we want to keep backward compatibility, the issue can be fixed
by adding pg_verifymbstr() to the function.
I don't feel good about changing the return type of an existing
function, so I guess +1 from me on the approach quoted above.
Ok, I just
On Sun, Jan 3, 2010 at 9:10 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
If we want to keep backward compatibility, the issue can be fixed
by adding pg_verifymbstr() to the function.
I don't feel good about changing the return type of
On Mon, Nov 30, 2009 at 4:36 AM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
If we want to keep backward compatibility, the issue can be fixed
by adding pg_verifymbstr() to the function. We can also have the
binary version in another name, like pg_read_binary_file().
I don't feel
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote:
pg_read_file() takes byte-offset and length as arguments,
but we don't check the result text with pg_verify_mbstr().
Should pg_read_file() return bytea instead of text or adding
some codes to verify the input? Only superusers are allowed
pg_read_file() takes byte-offset and length as arguments,
but we don't check the result text with pg_verify_mbstr().
Should pg_read_file() return bytea instead of text or adding
some codes to verify the input? Only superusers are allowed
to use the function, but it is still dangerous.
If we
