On Friday 10 October 2008 1:57:28 pm Adrian Klaver wrote:
> On Friday 10 October 2008 11:25:05 am Christopher Maier wrote:
> > On Oct 10, 2008, at 2:05 PM, Alvaro Herrera wrote:
> > > Looks like you should revoke DELETE privilege from plain users, and
> > > have your delete trigger be a security de
On Oct 10, 2008, at 4:53 PM, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Looks like you should revoke DELETE privilege from plain users, and
have your delete trigger be a security definer function. There
would be
another security definer function to delete non-deduced rows wh
On Friday 10 October 2008 11:25:05 am Christopher Maier wrote:
> On Oct 10, 2008, at 2:05 PM, Alvaro Herrera wrote:
> > Looks like you should revoke DELETE privilege from plain users, and
> > have your delete trigger be a security definer function. There
> > would be
> > another security definer f
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Looks like you should revoke DELETE privilege from plain users, and
> have your delete trigger be a security definer function. There would be
> another security definer function to delete non-deduced rows which users
> can call directly.
That seems ove
Hello list,
table diary_entry
entry_id SERIAL PK
d_entry_date_time timestamp without time zone
d_entry_company_id integer
d_entry_location_id integer
d_entry_shift_id integer
d_user_id integer
d_entry_header text
...
Get the last entries from companies and their locations?
The last, i.e. the bi
Christopher Maier wrote:
> Correct? That sounds like it would work. If at all possible, I'd like
> to keep the "interface" the same for all my tables, though (i.e., users
> don't have to be concerned with whether they can do regular SQL deletes,
> or if they have to call a special function).
On Oct 10, 2008, at 2:05 PM, Alvaro Herrera wrote:
Looks like you should revoke DELETE privilege from plain users, and
have your delete trigger be a security definer function. There
would be
another security definer function to delete non-deduced rows which
users
can call directly.
Thank
Christopher Maier wrote:
> However, I need to restrict deletion based on, for lack of a better
> term, "where" the DELETE command comes from. I do not want someone
> sitting at a psql console to be able to type:
>
> DELETE FROM my_table WHERE deduced IS TRUE;
Looks like you should revoke DELETE
On Oct 10, 2008, at 1:23 PM, Adrian Klaver wrote:
Could you have the the trigger examine the row to see if it meets
the criteria for deletion. If it does RETURN a NON NULL value so the
trigger completes, otherwise RETURN NULL to prevent the DELETE.
Thanks for your reply, Adrian. This is ind
-- Original message --
From: "Christopher Maier" <[EMAIL PROTECTED]>
> I have a table where some rows are originally entered, and others are
> logically deduced from original rows by triggers. For instance, if
> one row contains data indicating that "A < B" and
I have a table where some rows are originally entered, and others are
logically deduced from original rows by triggers. For instance, if
one row contains data indicating that "A < B" and another row
indicates "B < C", the triggers will generate a new row indicating
that "A < C". All deduc
[EMAIL PROTECTED] (Gerardo Herzig) writes:
> Hi all. Im facing a situation where i have to replicate a table from
> database A in databases B,C,F and so on.
>
> The first (and only) thing i have in mind is using triggers with dblink
> for comunications with the other DB's.
>
> I dont even like the
Hi all. Im facing a situation where i have to replicate a table from
database A in databases B,C,F and so on.
The first (and only) thing i have in mind is using triggers with dblink
for comunications with the other DB's.
I dont even like the idea of replicating tables across databases, but it
is
I find the problem is in my outer procedure, because it has no sleep there,
and I change it calling pg_sleep:
-- Function: "TestProcOuter"()
-- DROP FUNCTION "TestProcOuter"();
CREATE OR REPLACE FUNCTION "TestProcOuter"()
RETURNS integer AS
$BODY$
DECLARE
Loops int4 := 1;
BEGIN
With some version (but I don't remember which) I had the same problem.
I solved it by assigning TG_ARGV[0] to a variable and use the variable in the
RAISE NOTICE.
>>> Tom Lane <[EMAIL PROTECTED]> 2008-10-09 19:22 >>>
"Marcin Krawczyk" <[EMAIL PROTECTED]> writes:
> And here's what RAISE NOTICE lo
15 matches
Mail list logo
