Itagaki Takahiro itagaki.takah...@gmail.com writes:
I applied the attached patch extracted from Dimitri's work.
Thanks! I'm working on next extension's patch, merging now.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via
On Wed, Dec 15, 2010 at 12:55, Robert Haas robertmh...@gmail.com wrote:
It seems like pg_read_binary_file() is good to have regardless of
whatever else we decide to do here. Should we pull that part out and
commit it separately?
The whole-file versions seem like a good idea - my only
Tom Lane t...@sss.pgh.pa.us writes:
Has anyone thought twice about the security implications of that?
Not to mention that in most cases, the very last thing we want is to
have to specify an exact full path?
Well, the security is left same as before, superuser only. And Itagaki
showed that
Tom Lane t...@sss.pgh.pa.us writes:
CREATE EXTENSION will be superuser to start with, no doubt, but I think
we'll someday want to allow it to database owners, just as happened with
CREATE LANGUAGE. Let's not build it on top of operations that
inherently involve security problems, especially
Robert Haas robertmh...@gmail.com writes:
Well, I think it is best when a patch has just one purpose. This
seems to be sort of an odd hodge-podge of things.
The purpose here is clean-up the existing pg_read_file() facility so
that it's easy to build pg_execute_sql_file() on top of it.
On Tue, Dec 14, 2010 at 18:01, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
In any case, I concur with what I gather Robert is thinking, which is
that there is no good reason to be exposing any of this at the SQL level.
That used to be done this way, you know, in versions between 0 and 6 of
On Tue, Dec 14, 2010 at 11:48 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
I'm confused which part of the patch is the point of the discussion.
1. Relax pg_read_file() to be able to read any files.
2. pg_read_binary_file()
3. pg_execute_sql_string/file()
As I pointed out, 1 is
Robert Haas robertmh...@gmail.com writes:
So there are really four changes in here, right?
1. Relax pg_read_file() to be able to read any files.
2. pg_read_binary_file()
3. pg_execute_sql_string()/file()
4. ability to read a file in a given encoding (rather than the client
encoding)
I
On Tue, Dec 14, 2010 at 1:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So there are really four changes in here, right?
1. Relax pg_read_file() to be able to read any files.
2. pg_read_binary_file()
3. pg_execute_sql_string()/file()
4. ability to read
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
So there are really four changes in here, right?
1. Relax pg_read_file() to be able to read any files.
2. pg_read_binary_file()
3. pg_execute_sql_string()/file()
4. ability to read a file in a given encoding
On Wed, Dec 15, 2010 at 04:39, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Well, in fact, the extension's code is using either execute_sql_file()
or read_text_file_with_endoding() then @extschema@ replacement then
execute_sql_string(), all those functions called directly thanks to
#include
On Wed, Dec 15, 2010 at 03:42, Robert Haas robertmh...@gmail.com wrote:
I think #2 might be a nice thing to have, but I'm not sure what it has
to do with extensions.
Agreed. There might be some use for #4 in connection with extensions,
but I don't see that #2 is related.
BTW, it appears to
On Tue, Dec 14, 2010 at 9:25 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Dec 15, 2010 at 03:42, Robert Haas robertmh...@gmail.com wrote:
I think #2 might be a nice thing to have, but I'm not sure what it has
to do with extensions.
Agreed. There might be some use for #4 in
On Wed, Dec 15, 2010 at 12:20, Robert Haas robertmh...@gmail.com wrote:
It seems like pg_read_binary_file() is good to have regardless of
whatever else we decide to do here. Should we pull that part out and
commit it separately?
OK, I'll do that, but I have some questions:
#1 Should we add
On Tue, Dec 14, 2010 at 10:43 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Dec 15, 2010 at 12:20, Robert Haas robertmh...@gmail.com wrote:
It seems like pg_read_binary_file() is good to have regardless of
whatever else we decide to do here. Should we pull that part out and
On Sun, Dec 12, 2010 at 06:08, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
The other infrastructure patch that has been mark ready for commit then
commented further upon by Tom is $subject, even if the function provided
as been renamed to pg_execute_sql_file().
Please find attached the
Itagaki Takahiro itagaki.takah...@gmail.com writes:
I think the version is almost OK, but I have a couple of comments:
- Why do you need directory_fctx in genfile.h ?
I then use it in extension.c, this way:
typedef struct extension_fctx
{
directory_fctx dir;
ExtensionList
On Mon, Dec 13, 2010 at 9:36 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Do you want another patch version from me?
I'm looking at this patch and I'm confused. Why do we need this at
all? pg_read_binary_file() seems like it might be useful to somebody,
but I don't see what it has to do
On Tue, Dec 14, 2010 at 10:53, Robert Haas robertmh...@gmail.com wrote:
I'm looking at this patch and I'm confused. Why do we need this at
all? pg_read_binary_file() seems like it might be useful to somebody,
but I don't see what it has to do with extensions. And the rest of
this doesn't
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Tue, Dec 14, 2010 at 10:53, Robert Haas robertmh...@gmail.com wrote:
I'm looking at this patch and I'm confused. Â Why do we need this at
all? Â pg_read_binary_file() seems like it might be useful to somebody,
but I don't see what it has
On Mon, Dec 13, 2010 at 9:41 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
Hmm, I've expected that the EXTENSION patch would use the SQL functions
like as SPI_exec(SELECT pg_execute_sql(pg_read_file($1)), ...), but
it actually uses internal functions and nested DirectFunctionCalls.
On Tue, Dec 14, 2010 at 12:02, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 13, 2010 at 9:41 PM, Itagaki Takahiro
So, the most important part of this patch is allowing to read any
files in the server file system. The current pg_read_file() allows
to read only files under $PGDATA and
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Tue, Dec 14, 2010 at 12:02, Robert Haas robertmh...@gmail.com wrote:
As Tom says, this is clearly not going to fly on security grounds.
If it's a security hole, lo_import() should be also a hole
because we can use lo_import() and SELECT *
On Mon, Dec 13, 2010 at 10:21 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
I don't have any problem with a separate patch to try to improve some
of these issues, but this is supposedly part of the extensions work,
yet (1) most of what's here has little to do with extensions and (2)
On Tue, Dec 14, 2010 at 12:47, Tom Lane t...@sss.pgh.pa.us wrote:
lo_import is superuser-only. If we design this feature so that it will
forever have to be superuser-only, to get a behavior that I think we
don't even *want*, I believe we're making a serious error.
CREATE EXTENSION and
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Tue, Dec 14, 2010 at 12:47, Tom Lane t...@sss.pgh.pa.us wrote:
lo_import is superuser-only. Â If we design this feature so that it will
forever have to be superuser-only, to get a behavior that I think we
don't even *want*, I believe we're
Hi,
The other infrastructure patch that has been mark ready for commit then
commented further upon by Tom is $subject, even if the function provided
as been renamed to pg_execute_sql_file().
Please find attached the newer version that fixes Tom concerns, removing
the VARIADIC forms of the
27 matches
Mail list logo
