From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Ken Winter <ken(at)sunward(dot)org> |
Cc: | 'PostgreSQL pg-general List' <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why does an ON SELECT rule have to be named "_RETURN"? |
Date: | 2006-02-13 19:43:23 |
Message-ID: | 20060213092020.L24747@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Emi Lu | 2006-02-13 20:31:42 | Get affected table name in trigger function? |
Previous Message | Tom Lane | 2006-02-13 19:18:07 | Re: altering objects owned by other user |