x27;m not sure if this is workable yet, and it creates ugly
pointer-based backrefs *up* the Query chain, making what was previously
a tree of Query* 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
rtually ASSERTIVE (not enforcing). Should it also be noted
explicitly?
Backward compatibility
NOT NULL [ASSERTIVE] might be an option.
Thanks,
--
OSS Promotion Center / The PG-Strom Project
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
0,7 @@ save_backend_variables(BackendParameters *param, Port
*port,
param->SpinlockSemaArray = SpinlockSemaArray;
#endif
param->LWLockArray = LWLockArray;
+ param->MainLWLockArray = MainLWLockArray;
param->ProcStructLock = ProcStructLock;
param->ProcGlobal = Pr
(2014/01/21 11:44), Shigeru Hanada wrote:
Thanks for the comments.
2014/1/21 KaiGai Kohei :
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 by
(2014/01/22 1:37), Robert Haas wrote:
On Mon, Jan 20, 2014 at 11:23 PM, KaiGai Kohei 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 LWLockTr
(2014/01/21 18:18), Dean Rasheed wrote:
On 21 January 2014 01:09, KaiGai Kohei wrote:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner
didn't put post-creation hook
on foreign data wrapper, foreign server and user mapping
exceptionally. So, I put this hook around their command
handler like any other object classes.
Thanks,
(2010/11/24 12:07), Robert Haas wrote:
> 2010/11/23 KaiGai Kohei:
>>> What
>>> I'
function individually.
Rest of parts are revised according to the comment.
I also fixed up source code comments which might become incorrect.
Thanks,
(2010/11/18 11:30), Robert Haas wrote:
> 2010/11/17 KaiGai Kohei:
>> I revised my patch as I attached.
>>
>> The hook fun
(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. Reedstrom wrote:
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
If we don't need a PoC module for
mand
seems to me odd.
I think this patch fixes the behavior as we expected.
BTW, how about backporting this patch?
It seems to me a bug fix, although it contains user visible changes.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/11/26 11:35), Fujii Masao wrote:
On Thu, Nov 25, 2010 at 3:18 PM, KaiGai Kohei wrote:
The attached patch is revised version.
- Logging part within auth_delay was removed. This module now focuses on
injection of a few seconds delay on authentication failed.
- Documentation parts were
(2010/11/27 9:11), Robert Haas wrote:
> 2010/11/25 KaiGai Kohei:
>> (2010/10/16 4:49), Josh Kupershmidt wrote:
>>> [Moving to -hackers]
>>>
>>> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs
>>> wrote:
>>>> On Mon, 2010-10-11 at 09:41 -040
(2010/11/29 10:43), Robert Haas wrote:
> 2010/11/28 KaiGai Kohei:
>>> I'm not totally convinced that this is the correct behavior. It seems
>>> a bit surprising that UPDATE privilege on a single column is enough to
>>> lock out all SELECT activity f
ould try to tackle, is it?
Sorry, I don't have a credible idea to solve this inconsistency right now.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks for your reviewing.
The attached patch is a revised version.
I don't have any objections to your comments.
(2010/12/07 4:38), Robert Haas wrote:
> 2010/11/25 KaiGai Kohei:
>> The attached patch is a revised one.
>>
>> It provides two hooks; the one informs co
ols 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
(2010/12/13 21:53), Robert Haas wrote:
2010/12/12 KaiGai Kohei:
I'd like to see opinions what facilities should be developed
to the current v9.1 development cycle.
It seems to me that the next commit after the label-switcher-function
patch ought to be a contrib module that implements a
(2010/12/14 1:03), Robert Haas wrote:
> On Mon, Dec 13, 2010 at 8:32 AM, KaiGai Kohei wrote:
>> (2010/12/13 21:53), Robert Haas wrote:
>>> 2010/12/12 KaiGai Kohei:
>>>>
>>>> I'd like to see opinions what facilities should be developed
>>>&
(2010/12/14 9:32), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>>>> It is a good news for me also, because I didn't imagine SE-PostgreSQL
>>>> module getting upstreamed, even if contrib module.
>>>>
>>>> OK, I'll focus on the works to
(2010/12/14 10:41), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>>>> I counted number of lines of the sepgsql module that implement
>>>> only currently supported hooks. It has 3.2KL of code not.
>>>
>>> Uh, wow. That's rather surprising. I th
(2010/12/14 12:10), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> The starter version is not intended to use in production system,
>
> Well, what's the point, then? I thought we had enough infrastructure
> in place at this point to build a simple system that, while i
(2010/12/14 12:53), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> (2010/12/14 12:10), Robert Haas wrote:
>>> 2010/12/13 KaiGai Kohei:
>>>> The starter version is not intended to use in production system,
>>>
>>> Well, what's the point, then?
(2010/12/14 13:31), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> (2010/12/14 12:53), Robert Haas wrote:
>>> 2010/12/13 KaiGai Kohei:
>>>> (2010/12/14 12:10), Robert Haas wrote:
>>>>> 2010/12/13 KaiGai Kohei:
>>>>>>
(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 te
(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 th
(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
rio for us 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,
--
Ka
(2011/01/06 14:28), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> The attached patch is the modular version of SE-PostgreSQL (take.2).
>
> I'm reading through the documentation and so far it looks pretty
> reasonable. But I have some questions and suggested changes, of
&
people
this feature being worthful, so the contents tend to philosophical
things rather than actual specifications.
I also think wiki page allows us to brush up the documentation
rather than exchanging patches effectively. I'll set up a wiki page
that contains same contents with *.sgml file to revise documentation
stuff to be included into the *.sgml file finally. How about this idea?
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
instruction assumes your installation is under
the /usr/local/pgsql directory, and the database 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
re functions, and adding a 'bool *didUpdate'
> argument to some lower-level functions. I'm 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
--
t) using security-id (oid)
which is a primary key pointing out a certain text data 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
(2011/01/20 12:10), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> How about feasibility to merge this 4KL chunks during the rest of
>> 45 days? I think we should decide this general direction at first.
>
> I read through this code tonight and it looks pretty straightforwar
(2011/01/20 13:01), Robert Haas wrote:
> 2011/1/19 KaiGai Kohei:
>>> And how about adding a
>>> ProcessUtility_hook to trap evil non-DML statements that some
>>> nefarious user might issues?
>>>
>> It seems to me reasonable as long as the number of c
(2010/02/02 3:01), Robert Haas wrote:
> 2010/1/31 KaiGai Kohei:
>> The attached patch modified find_all_inheritors() to return the list of
>> expected inhcount, if List * pointer is given. And, it focuses on only
>> the bugs in renameatt() case.
>
> I have cleaned u
(2010/02/02 9:48), KaiGai Kohei wrote:
>>> Also, the ALTER COLUMN TYPE case should be also fixed in the 9.1 release
>>> (or 9.0.1?).
>>
>> If the fix is something we could commit for 9.0.1, then we ought to do
>> it now before 9.0 is released. If you want to su
(2010/02/02 9:33), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> Can we remove such path and raise an error instead?
>>> Also, even if we support the older servers in the routine,
>>> the new bytea format will be another problem anyway.
>>
>
(2010/02/02 11:09), Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code,
>> not only ATPrepAlterColumnType(), according to what I mentioned above.
>
> What exactly do you claim is wrong with the ADD COLUMN c
(2010/02/02 11:31), Robert Haas wrote:
> 2010/2/1 KaiGai Kohei:
>> (2010/02/02 11:09), Tom Lane wrote:
>>> KaiGai Koheiwrites:
>>>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn()
>>>> code,
>>>> not only ATPrep
(2010/02/02 11:44), Robert Haas wrote:
> 2010/2/1 KaiGai Kohei:
>> (2010/02/02 11:31), Robert Haas wrote:
>>> 2010/2/1 KaiGai Kohei:
>>>> (2010/02/02 11:09), Tom Lane wrote:
>>>>> KaiGai Kohei writes:
>>>>>> The attached one als
cause of the
restriction on implementation, not a data modeling reason.
Many of empty large objects may not be sane situation, but it is suitable
for the existing manner in pg_dump/pg_restore, at least.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/02/02 23:50), Robert Haas wrote:
> 2010/2/1 KaiGai Kohei:
>>> I'm making a general statement - if something is BROKEN (like the
>>> rename case we just dealt with), we should look at fixing it. If it's
>>> just something that could be cleaned up or
(2010/02/04 0:20), Robert Haas wrote:
> 2010/2/1 KaiGai Kohei:
>> I again wonder whether we are on the right direction.
>
> I believe the proposed approach is to dump blob metadata if and only
> if you are also dumping blob contents, and to do all of this for data
> dumps
(2010/02/04 17:30), KaiGai Kohei wrote:
> (2010/02/04 0:20), Robert Haas wrote:
>> 2010/2/1 KaiGai Kohei:
>>> I again wonder whether we are on the right direction.
>>
>> I believe the proposed approach is to dump blob metadata if and only
>> if you are also dum
(2010/02/05 3:27), Alvaro Herrera wrote:
Robert Haas escribió:
2010/2/4 KaiGai Kohei:
(2010/02/04 0:20), Robert Haas wrote:
2010/2/1 KaiGai Kohei:
I again wonder whether we are on the right direction.
I believe the proposed approach is to dump blob metadata if and only
if you are also
(2010/02/05 13:53), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> default:both contents and metadata
>>> --data-only:same
>>> --schema-only: neither
>>
>> However, it means only large object performs an exception
(2010/02/05 13:53), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> default:both contents and metadata
>>> --data-only:same
>>> --schema-only: neither
>>
>> However, it means only large object performs an exception
(2010/02/05 13:53), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> default:both contents and metadata
>>> --data-only:same
>>> --schema-only: neither
>>
>> However, it means only large object performs an exception
(2010/02/08 22:23), Alvaro Herrera wrote:
Takahiro Itagaki escribió:
KaiGai Kohei wrote:
default:both contents and metadata
--data-only:same
--schema-only: neither
However, it means only large object performs an exceptional object class
that dumps its
(2010/02/09 20:16), Takahiro Itagaki wrote:
KaiGai Kohei wrote:
I don't think this is necessarily a good idea. We might decide to treat
both things separately in the future and it having them represented
separately in the dump would prove useful.
I agree. From design perspective
(2010/02/09 21:18), KaiGai Kohei wrote:
> (2010/02/09 20:16), Takahiro Itagaki wrote:
>>
>> KaiGai Kohei wrote:
>>
>>>> I don't think this is necessarily a good idea. We might decide to treat
>>>> both things separately in the future and it having
to take a look? This is an open item, so we
> should really try to deal with it.
Do I have anything I can work on this right now?
Because I'll be unavailable at the next week, I'd like to fix up it
within this week, if possible.
--
OSS Platform Development Division, NEC
KaiGai
t's accomplishing the goal of making blobs
> work like normal objects.
It was also an idea that I tried to implement in this approach at first.
But it is difficult to treat various kind of pg_restore options correctly.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gai,ymj=r/kaigai}
16385 |16388 | {ymj=rw/ymj,tak=r/ymj}
16386 |16389 | {tak=rw/tak,ymj=r/tak}
(4 rows)
Thanks,
(2010/02/18 9:12), KaiGai Kohei wrote:
> (2010/02/18 4:54), Tom Lane wrote:
>> I've been looking at the proposed patch for pg_dump with large objects,
>>
or
view) or
the name of an individual column in a table. There is no effect on the
stored data.
It seems to me the renameatt() should check relkind of the specified relation,
and
raise an error if relkind != RELKIND_RELATION.
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers
(2010/03/03 11:22), Tom Lane wrote:
> KaiGai Kohei writes:
>> Is it an expected behavior?
>
> There's no particular reason to forbid it, is there?
Perhaps, it is harmless.
It just seemed to me the renameatt() was not implemented correctly
according to the documentati
(2010/03/03 14:26), Robert Haas wrote:
> 2010/3/2 KaiGai Kohei:
>> Is it an expected behavior?
>>
>> postgres=> CREATE SEQUENCE s;
>> CREATE SEQUENCE
>> postgres=> ALTER TABLE s RENAME sequence_name TO abcd;
>> ALTER TABLE
>>
>>
(2010/03/03 22:42), Robert Haas wrote:
> 2010/3/3 KaiGai Kohei:
>> (2010/03/03 14:26), Robert Haas wrote:
>>> 2010/3/2 KaiGai Kohei:
>>>> Is it an expected behavior?
>>>>
>>>>postgres=>CREATE SEQUENCE s;
>>>>CREATE
It looks like for me the bottom half of the DefineOpFamily() is
a block copied and pasted from CreateOpFamily().
It has identical logic, variable names and source code comments.
Perhaps, we can replace this code block by CreateOpFamily() call.
Thanks,
--
KaiGai Kohei
pgsql-cleanup
(2010/03/11 0:54), Robert Haas wrote:
> On Wed, Mar 3, 2010 at 7:16 PM, Robert Haas wrote:
>> 2010/3/3 KaiGai Kohei:
>>> (2010/03/03 22:42), Robert Haas wrote:
>>>> 2010/3/3 KaiGai Kohei:
>>>>> (2010/03/03 14:26), Robert Haas wrote:
>>>>>
(2010/03/11 23:55), Robert Haas wrote:
> 2010/3/10 KaiGai Kohei:
>> Indeed, it is useful to allow renaming attribute of composite types.
>>
>> However, it is also useless to allow to rename attribute of sequences,
>> but harmless, like renames on indexes. It seems to
I wonder whether the fmgr_info() is an appropriate choice at
fmgr_info_other_lang(), because user intended to call the foo(), not
plpgsql_call_handler(), although it actuall calls language call-handler
in fact.
I think fmgr_info_cxt_security() with ignore_security = true should
be used here, instead
(2010/03/20 11:17), Robert Haas wrote:
On Fri, Mar 19, 2010 at 8:11 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Mar 19, 2010 at 8:18 AM, Tom Lane wrote:
KaiGai Kohei writes:
When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
it makes server process cra
(2010/03/20 13:37), Tom Lane wrote:
> KaiGai Kohei writes:
>> Is it an expected behavior that PostgreSQL tries to execute foo() with
>> privileges of the owner of language call handler because of its security
>> definer property? This server crash is just a result.
>
&
Oid userId,
AclMode requiredPerms,
Bitmapset *selCols,
Bitmapset *modCols,
bool abort);
Thanks,
--
KaiGai Kohei
*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
constraints;
add index); So, we can rework them using separated checker functions,
so it is not a matter.
I marked it as returned with feedback.
At the 1st CF, we focus on the reworks of DML permission checks.
So, the rest of DDL works should be done on the 2nd.
Thanks,
(2010/03/17 16:26), KaiGai Kohei
(2010/07/21 19:35), KaiGai Kohei wrote:
> (2010/07/21 19:26), Robert Haas wrote:
>> 2010/7/21 KaiGai Kohei:
>>>> 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
>>>> ind
epends on the security label support
patch that I submitted before.
Thanks,
--
KaiGai Kohei
*** a/src/backend/bootstrap/bootparse.y
--- b/src/backend/bootstrap/bootparse.y
***
*** 246,252 Boot_CreateStmt:
(Datum) 0,
false,
(2010/09/02 11:57), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> Right now, it stands on a strict assumption that considers operators
>> implemented with built-in functions are safe; it does not have no
>> possibility to leak supplied arguments anywhere.
>>
>>
(2010/09/02 12:38), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> (2010/09/02 11:57), Robert Haas wrote:
>>> 2010/9/1 KaiGai Kohei:
>>>> Right now, it stands on a strict assumption that considers operators
>>>> implemented with built-in functions are saf
(2010/09/02 13:30), KaiGai Kohei wrote:
> (2010/09/02 12:38), Robert Haas wrote:
>> 2010/9/1 KaiGai Kohei:
>>> (2010/09/02 11:57), Robert Haas wrote:
>>>> 2010/9/1 KaiGai Kohei:
>>>>> Right now, it stands on a strict assumption that considers operators
RITY LABEL 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 r
(2010/09/13 20:46), Robert Haas wrote:
2010/9/13 KaiGai Kohei:
Robert, although you suggested that only one ESP module shall be
invoked on relabeling an object before, and I agreed this design
at that time, but I noticed that we cannot implement the following
behavior correctly.
SELinux
to me not difficult to alter columns of typed
tables subsequent 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
--
Sent via pgsql-hackers maili
ugh CREATE TYPE prohibits to create
a composite type without any attribute.
What does it mean a composite type with no attribute?
Or, do we need a restriction to prevent the last one attribute?
Rest of comments are below.
(2010/09/18 5:44), Peter Eisentraut wrote:
> On fre, 2010-09-17 at 18:15
(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
Robert, thanks for your reviewing and revising.
(2010/09/23 13:28), Robert Haas wrote:
> On Thu, Sep 16, 2010 at 11:12 PM, Robert Haas wrote:
>> 2010/9/14 KaiGai Kohei:
>>> The attached patch is a revised version, but a bit difference from what
>>> I introduced ye
(2010/09/24 11:53), Robert Haas wrote:
> 2010/9/23 KaiGai Kohei:
>>> Most of the contents of the new documentation section on external
>>> security providers seemed irrelevant to me, which I guess I can only
>>> blame myself for since I was the one who asked for that
where any backslash command
> is almost bound to be something not terribly mnemonic, and because
> there are likely to be either no security labels at all or so many
> that a command that just dumps them ALL out in bulk is all but
> useless. But we at least need to provide a suitable
(2010/09/24 20:56), Robert Haas wrote:
2010/9/23 KaiGai Kohei:
Please see http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php
OK, I'll emulate this approach at first.
Don't worry about this part - I will do this myself. If you can just
fix the pg_dump stuff, I thi
(2010/09/27 11:49), Robert Haas wrote:
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei wrote:
* The "dummy_esp" module and regression test for SECURITY LABEL statement.
This module allows only four labels: "unclassified", "classified",
"secret" and &
Thanks for your reviewing, and sorry for delayed responding due to
the LinuxCon Japan for a couple of days.
(2010/09/28 12:57), Robert Haas wrote:
2010/9/1 KaiGai Kohei:
This patch allows external security providers to check privileges
to create a new relation and to inform the security labels
Does the git.postgresql.org down?
Harada-san being also unreachable now.
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/09/29 20:53), Dave Page wrote:
2010/9/29 KaiGai Kohei:
Does the git.postgresql.org down?
Harada-san being also unreachable now.
Seems to be a network issue. It's fine for some people (like me), and
down for others.
Thom reports that it's now back for him.
Now I'm r
(2010/09/29 22:00), Robert Haas wrote:
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei wrote:
I don't think it is an option to move the hook after the pollution
of system catalogs, although we can pull out any information about
the new relation from syscache.
Why not?
All the exi
(2010/09/30 0:36), Robert Haas wrote:
> On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Kohei wrote:
>> (2010/09/29 22:00), Robert Haas wrote:
>>>
>>> On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheiwrote:
>>>>
>>>> I don't think it is an op
(2010/09/30 10:28), Robert Haas wrote:
> 2010/9/29 KaiGai Kohei:
>>> But with that exception,
>>> they seemed to think that coarse-grained permissions would be fine for
>>> a basic implementation: perhaps even just install something in
>>> ProcessUtility_h
(2010/10/01 3:09), Robert Haas wrote:
> 2010/9/29 KaiGai Kohei:
>> In addition, I want to give these entrypoints its name which
>> represents an appropriate purpose of the hook, rather than
>> a uniformed one.
>
> It sounds like you're proposing to create a vast nu
st of the times, which is a moderately common
> mistake. We already rely on localhost being (forward) resolvable for
> the stats collector.
>
> Something to think about: Maybe we need a quoting mechanism in case
> someone names their hosts "samenet".
>
>
>
>
ws is that I chose to remove the
> "missing_ok" argument from get_role_oid_or_public, so it's not a perfect
> mirror of it. None of the current callers need it, but perhaps people
> would like these functions to be consistent.
>
Tom Lane suggested to add mi
(2010/10/01 11:23), Robert Haas wrote:
> On Sep 30, 2010, at 9:01 PM, KaiGai Kohei wrote:
>> (2010/10/01 3:09), Robert Haas wrote:
>>> 2010/9/29 KaiGai Kohei:
>>>> In addition, I want to give these entrypoints its name which
>>>> represents an appropria
(2010/10/05 18:01), Itagaki Takahiro wrote:
> 2010/9/6 KaiGai Kohei:
>> The attached patch tackles both of the above two points, and allows to
>> control this deoptimization when CREATE SECURITY VIEW is used.
>
> I'll send a review for the patch.
>
Thanks fo
(2010/10/05 23:16), Robert Haas wrote:
2010/10/5 KaiGai Kohei:
The term "built-in functions" means functions written in INTERNAL language
here. But we also have SQL functions by default. Some of them are just a
wrapper to internal functions. I'm not sure the checking of INTERNAL
ain criteria, maybe, 'safe' flag in
pg_proc.
In my opinion, I like to categorize error 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
--
Sent via pgsql-hackers mailing li
(2010/10/06 0:33), KaiGai Kohei wrote:
> (2010/10/05 23:56), Tom Lane wrote:
>> Robert Haas 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 arit
p here, because
no commercial RDBMSs with RLS don't handle such kind of side-channel
attacks using key conflicts.
And, it seems to me the cost will be too expensive to care about the
case (3) and (4). So, I think it is worthless to fix up them.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ude.
The case 1 and 2 have differences from others. It allows to expose hidden
values, then people may be able to see these values without any inference.
So, their through-put is relatively faster than others. It means degree of
threat is also higher.
If we try to tacker to the matter 1 and 2, suggest
(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 wer
(2010/10/07 6:02), Robert Haas wrote:
> 2010/10/5 KaiGai Kohei:
>> I began to revise the security hooks, but I could find a few cases that does
>> not work with the approach of post-creation security hooks.
>> If we try to fix up the core PG routine to become suitable for
(2010/10/07 6:21), Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei:
However, we also have a few headache cases.
DefineType() creates a new type object and its array type, but it does not
call CommandCounterIncrement() b
1 - 100 of 909 matches
Mail list logo
