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 create a
Greg Stark gsst...@mit.edu writes:
On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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
2009/10/17 Dimitri Fontaine dfonta...@hi-media.com:
Tom Lane t...@sss.pgh.pa.us 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
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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.
Andrew Dunstan and...@dunslane.net 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
On Tue, Sep 22, 2009 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us 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,
Robert Haas robertmh...@gmail.com 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
On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Robert Haas robertmh...@gmail.com 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
12 matches
Mail list logo
