On Fri, Jun 8, 2018 at 8:27 AM, Adrian Klaver
wrote:
>
> Using INSTEAD OF trigger?:
>
Yep, that's one way.
> maybe it is time to overhaul the security concept.
>
I could see how I could revoke permissions from, say, all users that aren't
superusers to INSERT or UPDATE certain views. However, if possible it
would be nice to get an error message about the VIEW not being updatable,
rather than a user
Hello.
I enjoy using VIEWs. Often my views are updatable, either automatically
(due to being a simple 1-table view, or due to a TRIGGER). Sometimes they
are meant to be just read-only.
Is there any way to set a VIEW to be read-only -- specifically, can I do
this for a view that is
Hi David! Thanks for the reply.
> tableoid might be an exception to
> this, but it does not really seem like a useful column to index,
> giving it would be indexing the same value for each record in the
> table.
Unless you're using inheritance - then tableoid may vary. That's the case
I'm
Hello Postgressers,
I am using table inheritance and have e.g. the following tables:
create table animal ( ... );
create table dog ( ... ) inherits (animal);
create table cat ( ... ) inherits (animal);
create table person ( ... ) inherits (animal);
create table musician ( ...
Hello,
I heard at a PostgreSQL talk that you should not liberally create temp
tables in the course of frequently-used functions etc, because (roughly)
you're using up some of the same resources that you for your regular tables.
Is this true? Is there an important reason not to have e.g. a
