Re: Why does an ON SELECT rule have to be named "_RETURN"? - Mailing list pgsql-general

From Stephan Szabo
Subject Re: Why does an ON SELECT rule have to be named "_RETURN"?
Date
Msg-id 20060213092020.L24747@megazone.bigpanda.com
Whole thread Raw
In response to Re: Why does an ON SELECT rule have to be named "_RETURN"?  ("Ken Winter" <ken@sunward.org>)
List pgsql-general
On Mon, 13 Feb 2006, Ken Winter wrote:

> You're right: This thing I call a "view-table" would behave *exactly* like a
> view that has insert, update, and delete rules.
>
> The *only* difference I'm trying to achieve is to get it stored in
> pg_catalog.pg_class with relkind = 'r' ("ordinary table") rather than 'v'
> ("view").

The problem is that you're not just punning the type to the client.
You're punning the type to the server. Your "view-table" will be a table,
even for operations that might not work because it's really a view, and
the code isn't going to know to not allow it. If everything we had that
works for ordinary tables worked for views, it wouldn't be a problem, but
AFAIK that's not true.

> The *only* reason I'm trying to disguise a view as a table is to trick my
> client tools into letting me use their handy pre-made forms and grids to
> read and write to these structures.
>
> The reason I'm trying to activate these forms and grids is to enable my
> testing users to start entering and viewing test data immediately - without
> their having to learn and write SQL, and without my having to build data
> entry and review forms for them.
>
> I thought, all things considered, my little trick - admittedly a workaround
> - would be the easiest way to achieve what I need without requiring anything
> of either the PostgreSQL architects or the tool builders.  So it is
> frustrating to be defeated by this one PostgreSQL constraint (which isn't
> even published in the documentation, as far as I can see).

Well, it implies that create view and create table + create rule ...  on
select are equivalent, but I'd agree that this could probably be better
documented.

> I just had another workaround idea - declare the "view-table" as an ordinary
> table and put triggers on it that implement the functionality of the rules -
> but before resorting to that I thought I'd try my simpler trick once more.
>
> So let me ask again: Is there any way to disable this constraint that forces
> the SELECT rule to be named "_RETURN"?  Or is there any other way to
> accomplish what I'm trying to do?

Apart from modifying the code, I don't think so.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: altering objects owned by other user
Next
From: Emi Lu
Date:
Subject: Get affected table name in trigger function?