KaiGai Kohei wrote:
> 1) creation of a database object
>
> In SELinux model, when a user tries to create a new object (not limited
> to database object, like a file or socket), a default security context
> is assigned on the new object, then SELinux checks whether the user has
> privileges to crea
Greg Stark writes:
> On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane wrote:
>> However, if the columnref looks like "x.y" where x happens to
>> match some table in the database (and not in the query) that doesn't
>> have a column y, the implicit-RTE code will have already modified the
>> querytree bef
Tom Lane wrote:
> Greg Stark writes:
> > On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane wrote:
> >> However, if the columnref looks like "x.y" where x happens to
> >> match some table in the database (and not in the query) that doesn't
> >> have a column y, the implicit-RTE code will have already mod
Tom Lane writes:
> "Do nothing" isn't the right phrase here --- it would take a great deal
> of work and ugly, hard-to-maintain code to get it to work even that badly.
> The code paths in transformColumnRef are fairly messy already :-(.
> Getting rid of add_missing_from would definitely make it ea
2009/10/17 Dimitri Fontaine :
> Tom Lane writes:
>> "Do nothing" isn't the right phrase here --- it would take a great deal
>> of work and ugly, hard-to-maintain code to get it to work even that badly.
>> The code paths in transformColumnRef are fairly messy already :-(.
>> Getting rid of add_miss
Bruce Momjian writes:
> Sounds like a good reason to remove add_missing_from in 8.5.
Seems like the general consensus is that it's okay to do that.
I will go make it happen unless somebody squawks pretty soon...
regards, tom lane
--
Sent via pgsql-hackers mailing list (
Tom Lane wrote:
Bruce Momjian writes:
Sounds like a good reason to remove add_missing_from in 8.5.
Seems like the general consensus is that it's okay to do that.
I will go make it happen unless somebody squawks pretty soon...
Squawk. I am currently travelling. Please give me u
Andrew Dunstan writes:
> Squawk. I am currently travelling. Please give me until early next week
> to research and react.
Okay, I'll hold off for a bit. For reference, attached is the patch
I was about to apply. This doesn't do any of the refactoring I had
in mind, it just removes the implicit
On Tue, Sep 22, 2009 at 11:21 PM, Tom Lane wrote:
>> Currently, however, we only consider this possibility when the inner
>> rel is NOT a joinrel. It seems like it might be possible to change
>> this, but it doesn't look straightforward.
>
> Well, it's straightforward enough in theory, it's just
Robert Haas writes:
> Another thought, only semi-related. One of the big use cases for
> LATERAL in general is to use a set-returning function in the FROM
> clause that uses vars from a preceding FROM item. I am idly wondering
> if there's a reason why ExecProject is not its own node type.
You
On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
wrote:
> This raises an important point: We need *developer documentation* on how
> to write SE-Pgsql compliant permission checks. Not only for authors of
> 3rd party modules but for developers of PostgreSQL itself. Point 2)
> above needs to be e
Robert Haas writes:
> That still leaves a lot of silly paths, though. In many cases, if
> you're thinking about joining A to {B C} using an index-accelerated
> path, you'd be just as well off joining to B first and then to C. So
> it might be that we only need to consider index-accelerated paths
12 matches
Mail list logo
