On mån, 2010-12-13 at 14:45 +0900, Shigeru HANADA wrote:
> Simple FDWs such as File FDW might not have concept of "user" on
> remote side. In such case, it would be enough to control access
> privilege per local user with GRANT/REVOKE SELECT statement.
Right. But it depends on the implementation
On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
> It would be cool to be able to transparently use hstores as Python
> dictionaries and vice versa. It would be easy enough with hstore as a
> core type, but with hstore as an addon it's not that easy.
I have been thinking about this class of
On Dec13, 2010, at 18:37 , Robert Haas wrote:
> We're now just a day or two from the end of this CommitFest and there
> are still a LOT of open patches - to be specific, 23.Here's a brief
> synopsis of where we are with the others, all IMO of course.
Thanks for putting this together!
> - serializa
Robert Haas wrote:
I took a look at this and it looks generally good, but I'm wondering
why md.c is converting the results from an exact value to a floating
point, only to have xlog.c turn around and convert back to an integer.
I think it could just return milliseconds directly, or if you're
wor
On mån, 2010-12-13 at 10:55 -0500, Tom Lane wrote:
> We don't normally invent specialized syntax for a specific datatype.
> Not even if it's in core.
I think the idea would be to make associative arrays a kind of
second-order object like arrays, instead of a data type.
--
Sent via pgsql-hackers
On Tuesday 14 December 2010 00:14:22 Marko Tiikkaja wrote:
> The lock space is the same though, but I don't feel strongly about it.
I feel strongly that it needs the same locking space. I pretty frequently have
the need for multiple clients trying to acquiring a lock in transaction scope
(i.e. fo
Marko Tiikkaja writes:
> I often find myself wanting advisory locks that are automatically released
> when the transaction ends, so here's a small patch trying to do just that.
Excellent idea, I sure need that (been doing some pl stuff to track
locks granted then unlock them, transaction scope wo
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
On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
In my opinion changing current behavior is not a good idea. I know some
software that relies on current behavior and this would break it. Maybe add
that as an option, or add anoth
101 - 111 of 111 matches
Mail list logo
