2011/7/20 Robert Haas :
> On Tue, Jul 19, 2011 at 6:10 AM, Kohei Kaigai
> wrote:
>>> >> /etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid
>>> >> object
>>> >> type db_blobs
>>> > It is not an error, but
Yeb, Thanks for your volunteering.
> On 2011-07-14 21:46, Kohei KaiGai wrote:
> > Sorry, the syscache part was mixed to contrib/sepgsql part
> > in my previous post.
> > Please see the attached revision.
> >
> > Although its functionality is enough simple (it
> On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
> wrote:
> > One question is why InitCatalogCache() should be invoked from
> > InitPostgres()?
> > If we initialize syscache on starting up postmaster process, I think
> > all the syscache buckets will be rea
> On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
> wrote:
> > The sepgsql_restorecon(NULL) assigns default security label on all the
> > database objects being controlled, thus, its workload caches security
> > label (including text data) of these objects.
> > So,
> On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga wrote:
> > * I run SELECT sepgsql_restorecon(NULL) and saw comparable numbers in speed
> > gain and also backend process memory increase as indicated by KaiGai-san.
> > The vmsize without the patch increases from running restorecon 3864kB, with
> > th
How about an idea that allows to launch environment checker (typically shell
scripts) prior
to regression tests?
The following stuffs should be preconfigured to run sepgsql's regression test.
- SELinux must be run and configured to enforcing mode.
- The sepgsql-regtest policy module must be loade
2011/7/21 Yeb Havinga :
>
>> Is it possible to only include the syscache on --enable-selinux
>> configurations? It would imply physical data incompatibility with standard
>> configurations, but that's also true for e.g. the block size.
>>
>> Also, the tests I did with varying bucket sizes suggested
2011/7/21 Robert Haas :
> On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga wrote:
>> Is it possible to only include the syscache on --enable-selinux
>> configurations? It would imply physical data incompatibility with standard
>> configurations, but that's also true for e.g. the block size.
>
> Not re
> -Original Message-
> From: Yeb Havinga [mailto:yebhavi...@gmail.com]
> Sent: 22. Juli 2011 10:23
> To: Kohei Kaigai
> Cc: Robert Haas; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On 2011-07-21 11:29, Koh
2011/7/22 Yeb Havinga :
> On 2011-07-22 11:55, Kohei Kaigai wrote:
>>
>>> 2) Also I thought if it could work to not remember tcontext is valid, but
>>> instead remember the consequence,
>>> which is that it is replaced by "unlabeled". It makes the avc_
test label... ok
test dml ... ok
test misc ... ok
=
All 3 tests passed.
=
Thanks,
2011/7/22 Joe Conway :
> On 07/21/2011 05:35 AM, Robert Haas wrote:
>> On Thu, Jul 21, 2011 at 6:16 AM, Kohei K
Robert Haas wrote:
| I think that get_object_namespace() needs to be rethought. If you
| take a look at AlterObjectNamespace() and its callers, you'll notice
| that we already have, encoded in those call sites, the knowledge of
| which object types can be looked up in which system caches, and whic
2011/7/29 Tom Lane :
> Kohei Kaigai writes:
>> In addition to this suggestion, I think the big static array also contains
>> the following items:
>> - Text form of the object type (e.g, "table", "function", ...)
>
> What will you do wi
2011/8/2 Robert Haas :
> On Mon, Aug 1, 2011 at 4:27 PM, Alvaro Herrera
> wrote:
>> Excerpts from Robert Haas's message of lun ago 01 16:12:56 -0400 2011:
>>> On Mon, Aug 1, 2011 at 4:02 PM, Alvaro Herrera
>>> wrote:
>>> > Excerpts from Kohei KaiGai's message of dom jul 31 02:21:55 -0400 2011:
>>
BTW, what is the current status of this patch?
The status of contrib/sepgsql part is unclear for me, although we agreed that
syscache is suitable mechanism for security labels.
Thanks,
2011/7/22 Kohei KaiGai :
> 2011/7/22 Yeb Havinga :
>> On 2011-07-22 11:55, Kohei Kaigai wrote:
>>
2011/8/5 Robert Haas :
> On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai wrote:
>> BTW, what is the current status of this patch?
>
> I think it's waiting for me to get around to reviewing it. Sorry,
> been busy :-(
>
Thanks for your efforts.
>> The status of
e get_object_property_attnum_name(objtype) \
(get_object_property(objtype)->attnum_name)
2011/8/2 Kohei KaiGai :
> 2011/8/2 Robert Haas :
>> On Mon, Aug 1, 2011 at 4:27 PM, Alvaro Herrera
>> wrote:
>>> Excerpts from Robert Haas's message of lun ago 01 16:12:56 -0
2011/8/7 Tom Lane :
> Kohei KaiGai writes:
>> I'm under implementation of this code according to the suggestion.
>> However, I'm not sure whether it is really portable way (at least, GCC
>> accepts),
>> and whether the interface is simpler than as Ro
2011/8/8 Robert Haas :
> On Mon, Aug 8, 2011 at 11:57 AM, Alvaro Herrera
> wrote:
>> Excerpts from Kohei KaiGai's message of lun ago 08 03:12:20 -0400 2011:
>>
>>> Thanks for your suggestion.
>>> So, it seems to me the interface should return a pointer to the entry
>>> of array being specified, ra
om]
> Sent: 18. August 2011 17:53
> To: Kohei Kaigai
> Cc: Yeb Havinga; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote:
> > On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai
&g
ence Center
KaiGai Kohei
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: 18. August 2011 18:22
> To: Kohei Kaigai
> Cc: Yeb Havinga; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On
2011/8/18 Robert Haas :
> On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai
> wrote:
>>> That's lame. I think we need to patch contrib/sepgsql so that it
>>> fails to build in that case, rather than building and then not
>>> working.
>>>
>>
the way to validate executability of
psql command. (The point of this test is whether the psql is executable
by sepgsql_regtest_user_t, or not. So, bin_t is not a criteria to fail the
script.)
Thanks,
2011/8/18 Kohei Kaigai :
>> OK, I'm giving up for now. I hit two more sna
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: 19. August 2011 15:55
> To: Tom Lane
> Cc: Kohei KaiGai; Kohei Kaigai; Yeb Havinga; PgHacker
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On Fri, Aug 19,
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: 19. August 2011 16:34
> To: Kohei Kaigai
> Cc: Robert Haas; Kohei KaiGai; Yeb Havinga; PgHacker
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> Kohei Kaigai w
CreateExtension() possibly creates a new schema when the supplied
extension was not relocatable and the target schema was given by
control file of the extension.
However, it allows users to create a new schema with his ownership,
even if current user does not have permission to create a new schema.
2011/8/21 Dimitri Fontaine :
> Kohei KaiGai writes:
>> However, it allows users to create a new schema with his ownership,
>> even if current user does not have permission to create a new schema.
> [...]
>> It seems to me that we should inject permission checks here like a
, not only v9.2
development.
Thanks,
2011/8/21 Dimitri Fontaine :
> Kohei KaiGai writes:
>> The current implementation set the current user as owner of the new schema.
>> The default permission check of schema allows owner to create several kinds
>> of underlying objects.
&
Robert, Thanks for your reviewing.
> For me, the line you removed from dml.out causes the regression tests to fail.
>
Fixed. Why did I removed this line??
> I don't understand what this is going for:
>
> + /*
> + * To boost up trusted procedure checks on db_procedure object
> +
The attached patch is a draft to support arguments in addition to
OAT_* enum and object identifiers.
The existing object_access_hook enables loadable modules to acquire
control when objects are referenced. The first guest of this hook is
contrib/sepgsql for assignment of default security label on
> On Fri, Aug 26, 2011 at 5:32 AM, Kohei KaiGai wrote:
> > Yes. It also caches an expected security label when a client being
> > labeled as "scontext" tries to execute a procedure being labeled as
> > "tcontext", to reduce number of system call invocat
> I've committed this, but I still think it would be helpful to revise
> that comment. The turn "boosted up" is not very precise or
> informative. Could you submit a separate, comment-only patch to
> improve this?
>
I tried to put more detailed explanation about the logic of do { ... } while
loo
I tried to review this patch.
It seems to me its implementation is reasonable and enough simple.
All the works of this patch is pick-up "force_not_null" option from
pg_attribute.attfdwoptions and transform its data structure into suitable
form to the existing BeginCopyFrom().
So, I'd almost like t
t1 ORDER BY word1;
word1
---
123
abc
ABC
NULL
(4 rows)
Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of
> Shigeru Hanada
&
2011/9/7 Thom Brown :
> On 24 August 2011 13:38, Kohei Kaigai wrote:
>>
>> The (2) is new stuff from the revision in commit-fest 1st. It enables to
>> supply "NOLEAKY" option on CREATE FUNCTION statement, then the function is
>> allowed to distribute across
2011/9/7 Robert Haas :
> On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown wrote:
>> On 7 September 2011 14:34, Kohei KaiGai wrote:
>>> 2011/9/7 Thom Brown :
>>> > On 24 August 2011 13:38, Kohei Kaigai wrote:
>>> >>
>>> >> The (2) is new stuf
2011/9/7 Tom Lane :
> Noah Misch writes:
>> I liked NOLEAKY for its semantics, though I probably would have spelled it
>> "LEAKPROOF". PostgreSQL will trust the function to implement a specific,
>> relatively-unintuitive security policy. We want the function implementers to
>> read that policy c
2011/9/7 Andrew Dunstan :
>> LEAKPROOF isn't too bad.
>>
>>
>
> It's fairly opaque unless you know the context, although that might be said
> of some of our other terms too. Someone coming across it is going to think
> "What would it leak?"
>
It is introduced in the documentation. I'll add a point
ohei
> -Original Message-
> From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
> Sent: 8. September 2011 06:19
> To: Kohei Kaigai
> Cc: Kohei KaiGai; PostgreSQL-development
> Subject: Re: [HACKERS] force_not_null option support for file_fdw
>
> (2011/09/05 22:05
I marked this patch as "Ready for Committer", and hope this patch being
committed.
Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei
> -Original Message-
> From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
> Sent: 9. September 2011 06:03
>
The attached patch is a portion that we splitted off when we added
pg_shseclabel system catalog.
It enables the control/sepgsql to assign security label on pg_database
objects that are utilized as a basis to compute a default security
label of schema object.
Currently, we have an ugly assumption t
Hi Heikki,
I checked your patch, then I have a comment and two questions here.
The heap_prepare_insert() seems a duplication of code with earlier
half of existing heap_insert(). I think it is a good question to
consolidate these portion of the code.
I'm not clear the reason why the argument of
C
2011/9/24 Robert Haas :
> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
>> I updated the patches of fix-leaky-view problem, according to the
>> previous discussion.
>> The "NOLEAKY" option was replaced by "LEAKPROOF" option, and several
>&g
2011/9/23 Robert Haas :
> On Mon, Sep 12, 2011 at 5:45 AM, Kohei KaiGai wrote:
>> The attached patch is a portion that we splitted off when we added
>> pg_shseclabel system catalog.
>>
>> It enables the control/sepgsql to assign security label on pg_database
>&g
2011/9/26 Tom Lane :
> As a stopgap, what about removing sepgsql from the list of contrib
> modules tested by "make -C contrib check"? (I haven't looked at
> exactly how ugly it might be to do that, nor whether we'd have to also
> disable installcheck from recursing to sepgsql.)
>
Is it unavailabl
2011/9/26 Robert Haas :
> On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai wrote:
>>> I'm a bit nervous about storing security_barrier in the RTE. What
>>> happens to stored rules if the security_barrier option gets change
>>> later?
>>>
>> T
2011/9/26 Robert Haas :
> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>>> Robert Haas 09/25/11 10:58 AM >>>
>>>
>>> > I'm not sure we've been 100% consistent about that, since we
>>> > previously made CREATE OR REPLACE LAN
2011/9/26 Robert Haas :
> On Mon, Sep 26, 2011 at 6:28 AM, Kohei KaiGai wrote:
>> 2011/9/26 Robert Haas :
>>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>>>> On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>>>>> Robert Haas
2011/9/26 Tom Lane :
> Robert Haas writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment and then launches the tests.
>
2011/9/26 Robert Haas :
> On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai wrote:
>>> I think it is. If you create a view that involves an RTE, the node
>>> tree is going to get stored in pg_rewrite.ev_action. And it's going
>>> to include the security_barrier at
How about this fix on regression test of sepgsql?
It disables to launch regression test together with other modules,
and adds its own build target "sepgsql-installcheck" that launches
chkselinuxenv script then pg_regress command as currently we
are doing.
It allows users to launch regression test
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> However, the interface to reference reloptions are designed to pull
>> this information with Relation pointer, rather than lsyscache, so
>> I implemented this revision with a new rte->security_barrier member.
>
> This a
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> Sorry, are you saying the current (in other words, rte->security_barrier
>> stores the state of reloption) approach is not a good idea?
>
> Yes. I think the same as Robert: the way to handle this is to store it
> in Rel
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> One possible idea not to store the flag in RangeTblEntry is to utilize
>> rte->relid to show the relation-id of the source view, when rtekind is
>> RTE_SUBQUERY; that enables to pull the security_barrier flag in
>>
2011/9/26 Robert Haas :
> On Mon, Sep 12, 2011 at 3:31 PM, Kohei KaiGai wrote:
>> The Part-2 tries to tackles a leaky-view scenarios by functions with
>> very tiny cost
>> estimation value. It was same one we had discussed in the commitfest-1st.
>> It prevents to la
2011/9/26 Tom Lane :
> Kohei KaiGai writes:
>> How about this fix on regression test of sepgsql?
>
> IMO, the fundamental problem with the sepgsql regression tests is that
> they think they don't need to play by the rules that apply to every
> other PG regression test.
unchanged, except for rebasing to the latest git
master.
2011/8/28 Kohei KaiGai :
> The attached patch is a draft to support arguments in addition to
> OAT_* enum and object identifiers.
>
> The existing object_access_hook enables loadable modules to acquire
> control when objects are
2011/9/30 Noah Misch :
> On Sun, Sep 25, 2011 at 11:22:56PM -0400, Robert Haas wrote:
>> On Sun, Sep 25, 2011 at 10:38 PM, Noah Misch wrote:
>> > On Sun, Sep 25, 2011 at 11:22:03AM -0500, Kevin Grittner wrote:
>> >> Robert Haas ?09/25/11 10:58 AM >>>
>> >>
>> >> > I'm not sure we've been 100% cons
Hanada-san,
I applied your patch and run a few test cases. while this test, I
noticed a few points.
At first, I tried to use file_fdw, however, it was crashed of course.
It seems to me this logic should be modified to confirm whether the target FDW
support join push down, or not.
+ if (ena
"security" topic.
If someone volunteers to review this patch from the different viewpoint, not
only security features, it is quite helpful for us.
Thanks,
2011/9/29 Kohei KaiGai :
> I noticed that the previous revision does not provide any way to inform
> the modules name of foreign
Thanks for your reviewing.
2011/10/4 Robert Haas :
> On Wed, Sep 28, 2011 at 11:51 AM, Kohei KaiGai wrote:
>> I rebased the patches towards the latest git master, so I believe these
>> are available to apply.
>
> Reviewing away...
>
> I don't see why we need one
2011年10月4日12:08 Shigeru Hanada :
>> In my opinion, FdwRoutine should have an additional API to inform the core
>> its
>> supported features; such as inner-join, outer-join, order-by,
>> group-by, aggregate
>> functions, insert, update, delete, etc... in the future version.
>
> Sure, so in my desig
2011/10/8 Noah Misch :
> On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
>> My preference is still also WITH(security_barrier=...) syntax.
>>
>> The arguable point was the behavior when a view is replaced without
>> explicit WITH clause;
>> whether we
ows)
Probably, the basic design is correct. However, the planner gives
higher priority on the join plan between
local and foreign than pushing-down foreign relations.
Does it make sense not to consider any other possible plans when FDW
decided a particular join can be
pushed down?
Thanks,
2011年10月
2011/10/10 Robert Haas :
> On Wed, Oct 5, 2011 at 2:58 PM, Kohei KaiGai wrote:
>> Hmm. It indeed makes translation hard.
>> I reverted this portion of the part-2 patch, as attached.
>> Please review the newer one, instead of the previous revision.
>
> Please fix the com
> OK, well, I applied pgsql-v9.2-drop-reworks-2.v4.1.patch and tried to
> compile, and got this:
>
> In file included from ../../../src/include/catalog/dependency.h:17,
> from dependency.c:19:
> ../../../src/include/catalog/objectaddress.h:21: warning: type
> defaults to ‘int’ in de
2011/10/10 Robert Haas :
> On Sun, Oct 9, 2011 at 11:50 AM, Kohei KaiGai wrote:
>> I tried to refactor the patches based on the interface of WITH (...)
>> and usage of
>> pg_class.reloptions, although here is no functionality changes; including the
>> behavior when a
m OBJECT_* to
its text representation. (Maybe, it can be used to translattions with
opposite direction.)
Thanks,
2011/10/11 Robert Haas :
> On Mon, Oct 10, 2011 at 1:38 PM, Kohei KaiGai wrote:
>> I'm sorry again. I tought it was obvious from the filenames.
>
> I guess I got c
2011/10/12 Robert Haas :
> On Wed, Oct 12, 2011 at 8:07 AM, Kohei KaiGai wrote:
>> I'm currently trying to revise my patches according to your suggestions,
>> but I'm facing a trouble about error messages when user tries to drop
>> a non-exists object.
>>
&g
talog(). So, I should design the
hook to deliver new_rel_desc, instead of HeapTuple itself that need to
pull up from InsertPgClassTuple.
Thanks,
2011/10/12 Robert Haas :
> On Thu, Sep 29, 2011 at 4:52 PM, Kohei KaiGai wrote:
>> I noticed that the previous revision does not provide any w
I noticed a problem of get_object_address() with missing_ok = true.
When we try to solve the name of nonexistent rule/trigger/constraint on
a particular existing table, get_object_address_relobject() opens the
relation, but address.objectId = InvalidOid shall be set.
I think it should be closed i
, without this patch.
Thanks,
2011/10/13 Kohei KaiGai :
> I noticed a problem of get_object_address() with missing_ok = true.
>
> When we try to solve the name of nonexistent rule/trigger/constraint on
> a particular existing table, get_object_address_relobject() opens the
> relation, but a
1. Let quals percolate down into subqueries.
> 2. Add the notion of a security view, which prevents flattening and
> disables the optimization of patch #1
> 3. Add the notion of a leakproof function, which can benefit from the
> optimization of #1 even when the view involved is a securit
2015-05-18 15:15 GMT+09:00 Denis Kirjanov :
>
>
> - Ursprüngliche Mail -
> Von: "Kohei KaiGai"
> An: "Robert Haas"
> CC: "David G. Johnston" , "Denis Kirjanov"
> , pgsql-hackers@postgresql.org, "Kohei KaiGai"
>
2015-06-11 23:20 GMT+09:00 Jan Wieck :
> On 06/11/2015 09:53 AM, Kouhei Kaigai wrote:
>>>
>>> curious: what was work_mem set to?
>>>
>> work_mem=48GB
>>
>> My machine mounts 256GB physical RAM.
>
>
> work_mem can be allocated several times per backend. Nodes like sort and
> hash_aggregate may each
2015-06-11 23:28 GMT+09:00 Robert Haas :
> On Wed, Jun 10, 2015 at 10:57 PM, Kouhei Kaigai wrote:
>> The attached patch replaces this palloc0() by MemoryContextAllocHuge() +
>> memset().
>> Indeed, this hash table is constructed towards the relation with
>> nrows=119994544,
>> so, it is not stra
2015-06-11 23:33 GMT+09:00 Tomas Vondra :
> Hi,
>
> On 06/11/15 16:20, Jan Wieck wrote:
>>
>> On 06/11/2015 09:53 AM, Kouhei Kaigai wrote:
curious: what was work_mem set to?
>>> work_mem=48GB
>>>
>>> My machine mounts 256GB physical RAM.
>>
>>
>> work_mem can be allocated several tim
Does it make sense to put the result tuple of remote join on evety
estate->es_epqTupleSet[] slot represented by this ForeignScan if
scanrelid==0?
It allows to recheck qualifier for each LockRow that intends to lock
base foreign table underlying the remote join.
ForeignScan->fdw_relids tells us whi
2015-07-15 2:39 GMT+09:00 Ted Toth :
> That's exactly what I'm talking about like I said KaiGais branch was
> never merged into the mainline so I do not believe that it is used at
> all.
>
It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based sec
2011/10/18 Robert Haas :
> On Thu, Oct 13, 2011 at 6:48 AM, Kohei KaiGai wrote:
>> struct ObjectAccessInfoData {
>> ObjectAccessType oa_type;
>> ObjectAddress oa_address;
>> union {
>> struct {
>>
2011/10/18 Robert Haas :
> On Tue, Oct 18, 2011 at 11:25 AM, Kohei KaiGai wrote:
>> For example, I hope sepgsql to perform as follows when user create a new
>> table.
>> - It computes a default security label that needs Oid of the namespace.
>> - It checks db_table
2011/10/18 Robert Haas :
>> In the example table creation, heap_create_with_catalog() is invoked
>> by 5 routines, however, 3 of them are just internal usages, so it is not
>> preferable to apply permission checks on table creation
>
> Some wit once made the remark that if a function has 10 arg
2011/10/19 Tom Lane :
> Robert Haas writes:
>> On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai wrote:
>>> I tried to reproduce the scenario with enough small from/join_collapse_limit
>>> (typically 1), but it allows to push down qualifiers into the least scan
>&
2011/10/20 Robert Haas :
> On Thu, Oct 20, 2011 at 10:49 AM, Kohei KaiGai wrote:
>>>> part-3: drop statement reworks for other object classes
>>>
>>> This is going to need some rebasing.
>>>
>> OK, I rebased it.
>>
>> This patch incl
So, I will split the patch into two parts as follows, in the next commit fest.
Part-1) Views with security_barrier reloption
The part-1 portion provides views "security_barrier" reloption; that enables
to keep sub-queries unflatten in the prepjoin.c stage.
In addition, these sub-queries (that ori
How about the current status of this patch, although it is still
"Waiting on author".
If Hanada-san would propose contrib/pgsql_fdw as a basis of join-pushdown
feature, I'll likely volunteer to review the patch.
I'm also interested in this feature. Hopefully, I'd like to try other
kind of pushing
> When someone comes along in another year or two and adds materialized
> views, will they need to pass some additional data to the object
> access hook? Probably, but I bet you're the only one who can quickly
> figure out what it is. That's no good. We're not going to make
> changes to PostgreS
>> ATM I'm not sure it's even a good idea to push pgsql_fdw into contrib.
>> Once we do that its release schedule will get locked to core's ---
>> wouldn't it be better to keep flexibility for now, while it's in such
>> active development?
>
> I would be happy to keep it outside, and integrate it i
2011/10/26 Robert Haas :
> 2011/10/26 Shigeru Hanada :
>> (2011/10/25 19:15), Magnus Hagander wrote:
>>> 2011/10/25 Shigeru Hanada:
I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
contrib module. I think that this module would be the basis of further
SQL/MED
2011/10/21 Robert Haas :
> On Fri, Oct 21, 2011 at 12:44 PM, Kohei KaiGai wrote:
>> I had checked my older implementation based on 8.4.x or 9.0.x that
>> includes all the features that I want to implement.
>> At least, it does not require so much different information from
2011/11/1 Robert Haas :
> On Tue, Nov 1, 2011 at 1:32 PM, Kohei KaiGai wrote:
>> I tried to summarize permission checks of DAC/MAC on several object classes
>> that are allowed to assign security label right now.
>> http://wiki.postgresql.org/index.php?title=SEPostgreSQL/Perm
2011/11/2 Robert Haas :
> On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai wrote:
>> [ new patch, with example query plans ]
>
> I like the look of those query plans.
>
> Redefining the RangeTblEntry's relid field to be valid for either a
> table or a subquery that
Hanada-san,
I'm still under reviewing of your patch, so the comment is not overall, sorry.
I'm not sure whether the logic of is_foreign_expr() is appropriate.
It checks oid of the function within FuncExpr and OpExpr to disallow to push
down user-defined functions.
However, if a user-defined opera
2011/11/18 Robert Haas :
> On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai wrote:
>> Part-2) Groundworks on objectaddress.c
>> This patch adds necessary groundworks for Part-3 and Part-4.
>> It adds ObjectPropertyType of objectaddress.c index-oid and cache-id
>> for name
Thanks for your reviewing.
The reason of this strange message was bug is the patch.
> CREATE TABLE public.copy1(a, b) AS SELECT * FROM public.test;
> ERROR: whole-row update is not implemented
When it constructs a fake RangeTblEntry, it marked modifiedCols for
attribute 0 to (tupdesc->natts - 1
2011/11/26 Dimitri Fontaine :
> Kohei KaiGai writes:
>> We still don't have clear direction of the way to implement external
>> permission
>> checks on object creation time. So, please consider these patches are on the
>> proof-of-concept stage; using prep-cr
2011/11/21 Robert Haas :
>>> Now, what you have here is a much broader reworking. And that's not
>>> necessarily bad, but at the moment I'm not really seeing how it
>>> benefits us.
>>>
>> In my point, if individual object types need to have its own handler for
>> alter commands, points of the cod
2011/11/27 Dimitri Fontaine :
> Kohei KaiGai writes:
>>> I wonder if you could implement that as an extension given the command
>>> trigger patch finds its way in. What do you think?
>>>
>> Unfortunately, it does not solve my point.
>
> [...]
>
>&
2011/11/27 Dimitri Fontaine :
>> And, it seems to me the current proposition of the command trigger
>> does not support to fire triggers on creation of databases, although
>> permission checks requires Oid of source database that is not also
>> appeared in pg_database catalog.
>
> I have to have a
2011/11/28 Dimitri Fontaine :
> Kohei KaiGai writes:
>> How does it inherit an opaque private initialized at BEFORE trigger to
>> AFTER trigger? I checked your patch, however, it seems to me it does
>> not have a mechanism to deliver something between BEFORE and AFTER.
>
401 - 500 of 526 matches
Mail list logo
