t 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 <sfr...@snowman.net> wrote:
> * Zhaomo Yang (zmp...@gmail.com) wrote:
>> > Just a side-note, but your mail client doesn't seem to get the quoting
>>
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
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
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.
er commands).
Thanks,
Zhaomo
On Tue, Aug 25, 2015 at 8:17 AM, Stephen Frost <sfr...@snowman.net> wrote:
> Zhaomo,
>
> * Zhaomo Yang (zmp...@gmail.com) wrote:
> > > If no NEW or OLD is used, what happens? Or would you have
> > > to always specify OLD/NEW for UPDA
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
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
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
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
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
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
.
Thanks,
Zhaomo
On Tue, Jul 7, 2015 at 11:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hi
2015-07-08 9:08 GMT+02:00 Zhaomo Yang zhy...@cs.ucsd.edu:
more global temp tables are little bit comfortable for developers,
I'd like to emphasize this point. This feature does much more than saving
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
:
Zhaomo,
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
Have you considered just using a regular, but unlogged, table? That
would also avoid any risk that the application manages to drop or shadow
the temp table somehow with a fake table that changes who is currently
authenticated, and avoids
sfr...@snowman.net wrote:
Zhaomo,
As an FYI- we generally prefer inline responses rather than
top-posting on the PostgreSQL mailing lists. Thanks.
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
(1) Two philosophies important to our design
- Try to not force web application developers to make
,
* Zhaomo Yang (zhy...@cs.ucsd.edu) wrote:
I am a graduate student from UC San Diego. My adviser, Dr. Kirill
Levchenko, and I have been working on a web/DB security project for
the last few months. Since fine-grained access control in DBMS is part
of our project and the PostgreSQL community
of the mechanisms are accepted by the community, we also
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
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
18 matches
Mail list logo
