Tom Lane writes:
> case T_VacuumStmt:
> /* No XactReadOnly check since this logically changes no data */
> vacuum((VacuumStmt *) parsetree);
> break;
>
> Then it'll be hard to miss the need to think about this when adding a
> new statement.
Well, I had
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Where are you planning to check this?
> In general, I'm trying to align it like a (self-imposed) permission check.
> For the query-like statements I'm looking at ExecCheckRTPerms(). (That
> also handles EXECUTE and EXPLAIN most ea
Tom Lane writes:
> Where are you planning to check this?
In general, I'm trying to align it like a (self-imposed) permission check.
For the query-like statements I'm looking at ExecCheckRTPerms(). (That
also handles EXECUTE and EXPLAIN most easily.) Utility statements have a
check in tcop/utili
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I would like to implement read-only transactions following the SQL spec,
> ...
> I think it's light-weight and marginally useful.
"Light-weight" would depend on your intended implementation, I suppose.
Where are you planning to check this?
Also, the
I would like to implement read-only transactions following the SQL spec,
so we can check off this item on the supported list. According to the
list I gathered, the following commands will fail if the transaction is
read-only:
alter *
analyze
checkpoint
cluster
comment
create *
delete (from non-te
