(2014/01/21 18:18), Dean Rasheed wrote:
On 21 January 2014 01:09, KaiGai Kohei kai...@ak.jp.nec.com wrote:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
My first thought was that it should just preprocess any
(2014/01/22 1:37), Robert Haas wrote:
On Mon, Jan 20, 2014 at 11:23 PM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
I briefly checked the patch. Most of lines are mechanical replacement
from LWLockId to LWLock *, and compiler didn't claim anything with
-Wall -Werror option.
My concern is around
* into a graph. That could get exciting, though there'd
never be any need for mutators to follow the parent query pointer so it
wouldn't make tree rewrites harder.
--
OSS Promotion Center / The PG-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql
it also be noted
explicitly?
Backward compatibility
NOT NULL [ASSERTIVE] might be an option.
Thanks,
--
OSS Promotion Center / The PG-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
param-LWLockArray = LWLockArray;
+ param-MainLWLockArray = MainLWLockArray;
param-ProcStructLock = ProcStructLock;
param-ProcGlobal = ProcGlobal;
param-AuxiliaryProcs = AuxiliaryProcs;
Thanks,
--
OSS Promotion Center / The PG-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent
(2014/01/21 11:44), Shigeru Hanada wrote:
Thanks for the comments.
2014/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
In addition, an idea which I can't throw away is to assume that all
constraints defined on foreign tables as ASSERTIVE. Foreign tables
potentially have dangers to have wrong data
, please.
Also this word looks like a typo: seuciryt
The attached patch eliminated spaces before : %m, and
fixed up the typo.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
sepgsql-v9.1-fixup.2.patch
Description: application/octect-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers
(2011/01/27 0:25), Robert Haas wrote:
2011/1/25 KaiGai Koheikai...@ak.jp.nec.com:
(2011/01/26 12:23), KaiGai Kohei wrote:
Yikes. On further examination, exec_object_restorecon() is pretty
bogus. Surely you need some calls to quote_literal_cstr() in there
someplace.
Are you concerning
?
When these messages are because of unexpected operating system errors,
such as fails in communication with selinux, the %m will give us good
suggestions.
I'll submit these fixes within a few days, please wait for a while.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers
(2011/01/26 12:23), KaiGai Kohei wrote:
Yikes. On further examination, exec_object_restorecon() is pretty
bogus. Surely you need some calls to quote_literal_cstr() in there
someplace.
Are you concerning about the object name being supplied to
selabel_lookup_raw() in exec_object_restorecon
good, IMHO.
Thanks for your reviewing in spite of a large patch.
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in catalog table.
It well reduced storage consumption and achieved good performance in
comparison operation.
One challenge was to reclaim orphan texts. In this case, we needed to
lock out a user table referencing the toast values, then we delete all
the orphan entries.
Thanks,
--
KaiGai Kohei kai
not sure if passing back
the status in a bool* is considered good style, but this way all the
functions look consistent.
Regards,
Marti
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
cluster is
in /usr/local/pgsql/data. Substitute your paths appropriately.
It seems to me natural rather than using `pg_config --sharedir`
instead. (we might need to care about installation path of the
pg_config in this case.)
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers
into the *.sgml file finally. How about this idea?
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
time to fix
up the description.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is nothing were progressed in spite of
large man-power to review and discuss.
It may be more productive to keep features to be committed on the
last CF as small as possible, such as hooks to support a part of DDL
permissions or pg_regress enhancement to run regression test.
Thanks,
--
KaiGai Kohei
(2010/12/27 17:53), Simon Riggs wrote:
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say that clearly
(2010/12/30 9:34), Simon Riggs wrote:
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
What happens if someone alters the configuration so that the sepgsql
plugin is no longer installed. Does the hidden data become visible?
Yes. If sepgsql plugin is uninstalled, the hidden data become
(2010/12/24 11:53), KaiGai Kohei wrote:
There is one another issue to be discussed.
We need a special form of regression test. Because SE-PostgreSQL
makes access control decision based on security label of the peer
process, we need to switch psql process during regression test.
(So, I don't
.
I agree with these enhancements being pushed to v9.2 development.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
?
One idea is to add a few checks about selinux environment in
the configure script.
I counted number of lines of the sepgsql module that implement
only currently supported hooks. It has 3.2KL of code not.
How about scale of the patch to review?
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
for the first version.
The dml.c is as a literal. The hooks.c is entrypoints of hooks.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is not so large, implementations of post creation
hooks for language and largeobject can be stripped out, because we
don't have any hooks to apply access controls on these objects, so
labels of these objects are nonsense right now.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers
glaring than its
performance.
It is an independent topic whether it is useful for limited purpose,
or not. For example, when existing permission checks disallow all
the DDL commands from web-applications anyway, it will achieve an
expected role.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent
we_trust_you_a_lot_t to do any DDL?
No. Right now, it does not check anything on DDL commands, so all the
clients (independent from its security label) are allowed to run any
DDL commands, as long as existing permission allows it.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers
or
reasonable on DDL commands.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
at the following commands quite easy. It is an idea
to put hooks that we can implement with little impact around the
existing codes.
- GRANT/REVOKE
- COMMENT ON
- SECURITY LABEL
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
, FunctionCallEventType was also renamed to
FmgrHookEventType. Perhaps, it is a reasonable change.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
contrib/dummy_seclabel/dummy_seclabel.c | 107 -
src/backend/optimizer/util/clauses.c |8 ++
src/backend/utils/fmgr
a credible idea to solve this inconsistency right now.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
() might be a place where we also should fix.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that granting a user column-level update privileges doesn't
allow that user to issue LOCK TABLE with any mode other than Access
Share.
Do we need to answer: Yes, it is a specification, so you need to grant
table level privileges, instead?
Thanks
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via
, although it contains user visible changes.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
reasonable change.
I'll revise my patch. How about _PG_fini()?
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, instead of utils/hooks.h?
Well, if we're going to create a new header file for this, I think it
should be called something like catalog/objectaccess.h, rather than
just hooks.h. But I'd rather reuse something that's already there,
all things being equal.
--
KaiGai Kohei kai...@ak.jp.nec.com
whitespace changes.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
contrib/dummy_seclabel/dummy_seclabel.c | 102 -
src/backend/optimizer/util/clauses.c |8 ++
src/backend/utils/fmgr/fmgr.c | 44 ---
src/include/fmgr.h
(2010/11/19 16:57), KaiGai Kohei wrote:
(2010/11/18 2:17), Robert Haas wrote:
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstromreeds...@rice.edu wrote:
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Koheikai...@ak.jp.nec.com wrote
Thanks for your reviewing, and sorry for the late reply.
I've not been available for a few days.
(2010/11/22 12:11), Robert Haas wrote:
2010/11/12 KaiGai Koheikai...@ak.jp.nec.com:
(2010/11/12 19:34), KaiGai Kohei wrote:
I revised my patch according to the prior suggestions.
I'm sorry. I
in this weekend.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, please zap the unnecessary whitespace changes.
Indeed, the comment at middle of the fmgr_info_cxt_security() and just
above definition of the fmgr_security_definer() are not correct.
Did you notice anything else?
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list
to log superuser logins. Since that seems a
bit off-topic for a contrib module called auth_delay, and since we
already have a GUC called log_connections, I'm inclined to propose
removing that part.
I agree with the suggestion.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql
up regression test, dummy_seclabel module and its
documentation as Robert pointed out in another topic.
Thanks,
(2010/11/14 13:16), KaiGai Kohei wrote:
(2010/11/14 11:19), Robert Haas wrote:
2010/11/12 KaiGai Koheikai...@kaigai.gr.jp:
The attached patch allows the security label provider
know whether or not the function is a trusted
procedure by asking to the security policy. It is a task of the plugin.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
mechanism.
I believe it will be a clear guidance for the future maintenance works.
Thanks,
(2010/11/11 7:41), KaiGai Kohei wrote:
(2010/11/11 3:00), Robert Haas wrote:
On Wed, Nov 10, 2010 at 8:33 AM, KaiGai Koheikai...@kaigai.gr.jp wrote:
(2010/11/10 13:06), Robert Haas wrote:
In this patch, we
(2010/11/12 19:34), KaiGai Kohei wrote:
I revised my patch according to the prior suggestions.
I'm sorry. I revised my patch, but not attached.
Please see this attached one.
Thanks,
Invocation of the hooks is encapsulated within macro, not function:
+ #define InvokeObjectAccessHook0
or a valid label
if the supplied function is a label switcher. It also informs
the PG core whether the function is switcher or not.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
pgsql-switcher-function.1.patch
Description: application/octect-stream
--
Sent via pgsql-hackers mailing list (pgsql
of objects to which it's sensible
to apply security labels.
Because I thought too many hooks within one patch gives burden to reviewers,
so I restricted it on a part of object classes in this version.
However,it is not a compelling reason.
OK, I'll try to revise the patch soon.
Thanks,
--
KaiGai Kohei
preference function call here, so, I'll revise my
patch according to your vote.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
() for aggregates/functions
- TypeCreate() and TypeShellMake() for types
- create_proc_lang() for procedural languages
- inv_create() for large objects
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
*** a/src/backend/catalog/heap.c
--- b/src/backend/catalog/heap.c
***
*** 61,66
--- 61,67
for DDL triggers (if it has something like BEFORE/AFTER)?
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on
authentication fails prevents (or makes hard at least) brute-force
attacks, because it limits number of candidates that attacker can
verify within a unit of time.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
pgsql-v9.1-auth-delay.1.patch
Description: application/octect-stream
--
Sent via pgsql-hackers
max_connections even with the module.
Good point. The pam_faildelay being the model of this feature also
does nothing for flood of connections attack.
However, if it closes the connection immediately, the attacker can
try to verify next candidate very soon. Do you have any good idea?
Thanks,
--
KaiGai
to
kill two birds in a stone (hook) now.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
like to suggest to revise the specifications of permission
checks on these commands. If we can ensure these functions are not
malicious, no need to care about information leaks via untrusted
functions internally used.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list
to be
estimated. If a malicious one tries to make other users to invoke
a trojan-horse, he can define a trappy operator with malicious
estimator functions, cannot it?
This is a pretty poor excuse for a Trojan horse attack.
...Robert
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql
pointed out, but user can inform on which does he give higher priority.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the upcoming DDL permission checks.
Anyway, let's have a discussion when we put security hooks for DDL checks.
But the next patch will focus on assignment of security label at object
creation.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
(2010/10/15 22:04), Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
However, it requires the plugin modules need to know everything;
such as what is visible/invisible. It seems to me too closely-
coupled interface.
I agree with Robert on this one. We're
threat. It also means degree of the threat is
relatively small than the overt channels.
Previous security researcher pointed out security is trading-off,
not all-or-nothing. If we can plug most part of the threat with
reasonable performance degrading, it is worthwhile to fix up.
Thanks,
--
KaiGai
it is not impossible...
However, it requires the plugin modules need to know everything;
such as what is visible/invisible. It seems to me too closely-
coupled interface.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
, because it allows
users to prevent accesses unprivileged tables, if we check these
ownership at once later.
I learned existing privilege-checks are located with their reasons.
So, it seems to me a good strategy to follow on existing design.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent
(2010/10/12 3:34), Peter Eisentraut wrote:
On tor, 2010-10-07 at 12:45 +0900, KaiGai Kohei wrote:
* The logic is still unclear for me.
The check_hostname() immediately returns with false, if the resolved
remote hostname is NOT matched with the hostname described in pg_hba.conf
to
understand and maintain.
Thanks,
(2010/10/08 9:39), KaiGai Kohei wrote:
(2010/10/08 0:21), Robert Haas wrote:
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of miƩ oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Koheikai
become small, if we can put
security hooks independent from MVCC visibility.
Perhaps, the problem may be intangible, but I don't think it is fair
enough if we have to pay attention about MVCC visibility of plugin
modules whenever we try to apply a patch around creation hooks.
Thanks,
--
KaiGai
such a simple principle overs our capability, and
also don't think it is more complex than matters around the idea of
only post-creation hooks, such as CommandCounterIncrement().
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
of system catalogs.
It seems to me quite easy to understand and maintain.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a CCI only
if a hook is present.
The problem I see with this idea is that it becomes a lot harder to
track down whether it ocurred or not for any given operation.
Yes, it is a burden of code maintenance.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql
to be consistent.
Tom Lane suggested to add missing_ok argument, although it is not a must-
requirement.
Actually I think he suggested the opposite.
Ahh, I understood his suggestion as literal.
Well, I'd like to mark this patch as 'ready for committer'.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
(2010/10/06 10:21), KaiGai Kohei wrote:
I'll check the patch for more details, please wait for a few days.
I could find out some matters in this patch, independent from the
discussion of localhost. (About pg_hba.conf.sample, I'm sorry for
the missuggestion. Please fix up it according to Tom's
for each object classes are just prep
creation hooks. It does not seem to me explosion of security hooks.
Could you give me your opinion to handle these problematic code paths?
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
. Perhaps, 'relissecview'?
Thanks
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
messages as side-channel,
because its through-put is much less than regular-channels, so scale
of the threat is relatively small.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
(2010/10/06 0:33), KaiGai Kohei wrote:
(2010/10/05 23:56), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Checking the functions of the operators is the right thing to do, but
assuming that internal = safe does not work. For example, pushing
down arithmetic operators allows you
). So, I think it is worthless to fix up them.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/10/06 4:41), Peter Eisentraut wrote:
On tis, 2010-10-05 at 12:35 +0900, KaiGai Kohei wrote:
It seems to me this patch has been left for a long time, although it tries
to provide a useful functionality.
In the previous discussion, several issues were pointed out.
* Case handling when
: Maybe we need a quoting mechanism in case
someone names their hosts samenet.
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
these functions to be consistent.
Tom Lane suggested to add missing_ok argument, although it is not a must-
requirement.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
and event types, it may allows the main hook to handle most of
security checks, even if we need to add various flavors.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Does the git.postgresql.org down?
Harada-san being also unreachable now.
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
reachable to the git.postgreql.org.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
SCHEMA statement.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
In this approach, we eventually need to deploy the hooks on object creation
as we are currently working on. So, I don't think using ProcessUtility_hook
for coarse-grained permissions is a right direction.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql
;
/*
* check_relation_create
*
* This hook is invoked when ...
:
:
* If violated, guest of the hook can raise an error.
*/
void
check_relation_create(Oid oid)
{
if (object_access_hook != NULL)
object_access_hook(OBJECT_TABLE, oid, OAT_CREATE);
}
Thanks,
--
KaiGai Kohei kai
.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
as an internal format).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
in the next patch.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
about the patch to the backend
you revised, so I'd like to submit the next patch as an incremental
one to the seclabel-v4.patch, except for src/bin/pg_dump.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
? It seems to me a bit
inflation of number of system views.
My preference is psql's \d commands at first.
Please see http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php
OK, I'll emulate this approach at first.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql
plan to work on extending that later.
The restriction by find_composite_type_dependencies() was already there
for altering tables, and I just kept it the same for now.
Thanks for your explanation. It made me clear.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers
(2010/09/22 5:17), Peter Eisentraut wrote:
On tis, 2010-09-21 at 17:53 +0900, KaiGai Kohei wrote:
Sorry, I missed a bug when we create a typed table using composite
type which has been altered.
Perhaps, we also need to patch at transformOfType() to
skip attributes with attisdropped
with this ALTER TYPE, although it might be
not easy to alter definitions of embedded composite type already
in use.
Of course, it may be our future works. If so, it's good.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
patch within a couple of days.
Thanks,
Note that presumably COMMENT ON would need similar
treatment, and there may be other things.
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
statement, apart from whether
it manages the supplied security label, or not.
Thanks,
(2010/08/31 15:27), KaiGai Kohei wrote:
The attached patch is a revised version of security label support.
summary of changes:
* The logic to translate object-name to object-id was rewritten
with the new
(2010/09/02 13:30), KaiGai Kohei wrote:
(2010/09/02 12:38), Robert Haas wrote:
2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:
(2010/09/02 11:57), Robert Haas wrote:
2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:
Right now, it stands on a strict assumption that considers operators
implemented
(2010/07/21 19:35), KaiGai Kohei wrote:
(2010/07/21 19:26), Robert Haas wrote:
2010/7/21 KaiGai Koheikai...@ak.jp.nec.com:
On the other hand, if it's enough from a performance
point of view to review and mark only a few built-in functions like
index operators, maybe it's ok.
I also think
on the security label support
patch that I submitted before.
Thanks,
--
KaiGai Kohei kai...@ak.jp.nec.com
*** a/src/backend/bootstrap/bootparse.y
--- b/src/backend/bootstrap/bootparse.y
***
*** 246,252 Boot_CreateStmt:
(Datum) 0,
false
1 - 100 of 907 matches
Mail list logo