e won't be considered for 9.5 but I'd like to implement it and
hopefully get it incorporated into 9.6.
Thanks,
Zhaomo
On Wed, Sep 23, 2015 at 11:54 AM, Stephen Frost wrote:
> * Zhaomo Yang (zmp...@gmail.com) wrote:
>> > Just a side-note, but your mail client doesn't seem to
Stephen,
> Just a side-note, but your mail client doesn't seem to get the quoting
> quite right sometimes, which can be confusing. Not sure if there's
> anything you can do about it but wanted to let you know in case there
> is.
Sorry about this. From now on I'll use the plain text mode for msgs
Stephen,
It'd be great if others who are interested can help define the grammar
> changes necessary
> and perhaps even help with the code aspect of it.
I'd like to help on both. Can you elaborate a little bit more, especially
on the code aspect?
I don't buy that argument.
It is agreed that blin
Stephen,
> I agree that if we force a single visibility policy for all commands
> then we wouldn't need the USING clauses for UPDATE and DELETE, but we
> would certainly need *some* policy for DELETE to prevent users from
> being able to delete records that they aren't supposed to be allowed to.
>
some related
discussions (applying SELECT policy to other commands).
Thanks,
Zhaomo
On Tue, Aug 25, 2015 at 8:17 AM, Stephen Frost wrote:
> Zhaomo,
>
> * Zhaomo Yang (zmp...@gmail.com) wrote:
> > > If no NEW or OLD is used, what happens? Or would you have
> > > to alw
Stephen,
If no NEW or OLD is used, what happens? Or would you have
> to always specify OLD/NEW for UPDATE, and then what about for the other
> policies, and the FOR ALL policies?
I should be clearer with references to OLD/NEW. SELECT Predicates cannot
reference any of them.
INSERT predicates ca
In case you missed the link to the previous discussion at the bottom,
http://www.postgresql.org/message-id/CAHGQGwEqWD=ynqe+zojbpoxywt3xlk52-v_q9s+xofckjd5...@mail.gmail.com
Hi,
This thread has a pretty thorough discussion of pros and cons of applying
SELECT policy to other commands. Besides what have been mentioned, I think
there is another potential pro: we can enable references to pseudorelations
OLD and NEW in predicates. Now, for UPDATE, the references to the tar
>
> Just to be clear, the idea of a global temp table is that the table def
> is available to all users, but the data is private to each session?
The table def is visible to all sessions and persistent, but the data is
private to each session and temporary.
Thanks,
Zhaomo
> Sounds fine in general. I'm a bit curious to know what are the locking
implications of > vivifying the table on access.
The locking implications depend on how we interpret the existing commands
in the context of global temp tables and I think we should discuss and
agree on the behaviors of the c
> there is other question - what is effect of ALTER TABLE of global temp
table on
> instances of this table in active sessions?
As I said, we need to first agree on the behaviors of the existing
commands. I can think of two options now for ALTER TABLE: 1) only allow
ALTER TABLE when there is no
session.
Thanks,
Zhaomo
On Tue, Jul 7, 2015 at 11:53 PM, Pavel Stehule
wrote:
> Hi
>
>
> 2015-07-08 9:08 GMT+02:00 Zhaomo Yang :
>
>> > more global temp tables are little bit comfortable for developers,
>> I'd like to emphasize this point. This feature does much mor
> more global temp tables are little bit comfortable for developers,
I'd like to emphasize this point. This feature does much more than saving a
developer from issuing a CREATE TEMP TABLE statement in every session. Here
are two common use cases and I'm sure there are more.
(1)
Imagine in a web a
(e.g.
this mail list) so that people can try it.
Thanks,
Zhaomo
On Sat, Sep 13, 2014 at 4:00 PM, Stephen Frost wrote:
> Zhaomo,
>
> * Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
>> > Have you considered just using a regular, but unlogged, table? That
>> > wou
CAC cards with client-side certificates.
You are absolutely right. I should've explained it better. I just
wanted to show how authentication works and skipped all the hashing
part.
Thanks,
Zhaomo
On Fri, Sep 5, 2014 at 5:52 PM, Stephen Frost wrote:
> Zhaomo,
>
> As an FYI- we gene
specific
instructions on how to write an authentication function, we hope they
would find it easy to write one. Admittedly, however, what CREATE
AUTHENTICATION FUNCTION does can be achieved by CREATE FUNCTION.
Please let me know if you have any other questions.
Zhaomo
On Thu, Sep 4, 2014 at 6:53 PM, Step
would like to take part in implementing it. Please feel free to
contact us if you have any questions.
Zhaomo Yang zhy...@ucsd.edu
Kirill Levchenko klevc...@ucsd.edu
References:
[1] S. Chaudhuri, T. Dutta, and S. Sudarashan. Fine Grained
Authorization Through Predicated Grants. In
Hi folks,
I'm working on a project where I need to run some commands/functions when
SELECT are executed on certain tables. I looked at the rule system and
found the following paragraph in the documentation:
"Currently, there can be only one action in an ON SELECT rule, and it
must be an uncondi
18 matches
Mail list logo
