Itagaki Takahiro 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 pgsql-hackers mailing list (pgsql-
On Wed, Dec 15, 2010 at 12:55, Robert Haas 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 hesitation is,
>
On Tue, Dec 14, 2010 at 10:43 PM, Itagaki Takahiro
wrote:
> On Wed, Dec 15, 2010 at 12:20, Robert Haas 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
On Wed, Dec 15, 2010 at 12:20, Robert Haas 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 'whole' versions of
On Tue, Dec 14, 2010 at 9:25 PM, Itagaki Takahiro
wrote:
> On Wed, Dec 15, 2010 at 03:42, Robert Haas 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,
>>> b
On Wed, Dec 15, 2010 at 03:42, Robert Haas 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 me th
On Wed, Dec 15, 2010 at 04:39, Dimitri Fontaine 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 "utils/genfile.h".
Tom Lane writes:
> Robert Haas 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
>> encod
On Tue, Dec 14, 2010 at 1:38 PM, Tom Lane wrote:
> Robert Haas 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 (
Robert Haas 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 think I agree tha
On Tue, Dec 14, 2010 at 11:48 AM, Itagaki Takahiro
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 reasonable as long as
On Tue, Dec 14, 2010 at 18:01, Dimitri Fontaine 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
> the patch. Star
Robert Haas 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.
Regards,
--
Dimitri Fontai
Tom Lane 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 when there's no
Tom Lane 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 superuser are allowe
Itagaki Takahiro writes:
> On Tue, Dec 14, 2010 at 12:47, Tom Lane 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 EXT
On Tue, Dec 14, 2010 at 12:47, Tom Lane 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 pg_read_file() is also
On Mon, Dec 13, 2010 at 10:21 PM, Itagaki Takahiro
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)
>> extensions don't nee
Itagaki Takahiro writes:
> On Tue, Dec 14, 2010 at 12:02, Robert Haas 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 * FROM pg_largeobject
> for the same purpose
On Tue, Dec 14, 2010 at 12:02, Robert Haas 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 pg_log.
>
> As To
On Mon, Dec 13, 2010 at 9:41 PM, Itagaki Takahiro
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.
> So, the most important
Itagaki Takahiro writes:
> On Tue, Dec 14, 2010 at 10:53, Robert Haas 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
>
On Tue, Dec 14, 2010 at 10:53, Robert Haas 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 appear to provide an
On Mon, Dec 13, 2010 at 9:36 AM, Dimitri Fontaine
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 with extensions. And
Itagaki Takahiro 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 *installed;
} extension_fctx;
On Sun, Dec 12, 2010 at 06:08, Dimitri Fontaine 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 newer version that fi
26 matches
Mail list logo
