Added to TODO:
* Allow BEFORE INSERT triggers on views
http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php
---
Tom Lane wrote:
> "Karl O. Pinc" <[EMAIL PROTECTED]> writes:
>
On 02/24/2007 11:24:40 PM, Jaime Casanova wrote:
On 2/24/07, Karl O. Pinc <[EMAIL PROTECTED]> wrote:
http://www.postgresql.org/docs/current/static/rules-views.html
Actually, i found it very clear: if you create a SELECT rule on a
table it becomes a view, this is what postgres does every time
On 2/24/07, Karl O. Pinc <[EMAIL PROTECTED]> wrote:
(Important stuff last.)
On 02/24/2007 07:48:58 PM, Tom Lane wrote:
> The reason there will never be an insertion trigger event is that we
> reject any INSERT on a view that isn't rewritten (by an unconditional
> DO INSTEAD rule) into something
On 02/24/2007 08:55:40 PM, Tom Lane wrote:
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
NEW and OLD only include the user-visible columns. I'm not sure that
that's sufficient. If you assume that the view exposes a primary key
for each of its underlying tables, then you could use the pkey values
On 02/24/2007 08:48:04 PM, Karl O. Pinc wrote:
Ah, NEW and OLD are only good in the WHERE part
of the rule, which is still in "query land"
country before execution starts.
No. I'm wrong here.
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
--
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> On 02/24/2007 07:48:58 PM, Tom Lane wrote:
>> However, I'm not sure that the idea scales to cover updates and
>> deletes; with no concept of physical tuple identity (ctid) for the
>> view rows, it's not clear that you can write triggers that will
>> reli
On 02/24/2007 08:30:21 PM, Karl O. Pinc wrote:
How is it that the rules
can come up with NEW and OLD for a view and why wouldn't
something be able to give triggers the same data.
Ah, NEW and OLD are only good in the WHERE part
of the rule, which is still in "query land"
country before executi
(Important stuff last.)
On 02/24/2007 07:48:58 PM, Tom Lane wrote:
The reason there will never be an insertion trigger event is that we
reject any INSERT on a view that isn't rewritten (by an unconditional
DO INSTEAD rule) into something else.
(Yup. But I tried to make my own view implimentat
> I recall a prior discussion about making it possible to use triggers on
> views as a substitute for DO INSTEAD rules, by removing the rewrite-time
> check and only erroring out if we actually get to the point of
> attempting a physical insert. Then a BEFORE INSERT trigger could do
> something a
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> why can't I put a SELECT rule on a table?
Because then it would be a view.
As for $SUBJECT, the problem is that there will never be an insert into
a view --- not at the level of a physical insert attempt anyway --- and
thus there is nothing for a trigg
On 02/24/2007 06:55:45 PM, Webb Sprague wrote:
I also think that a view is supposed to be just that -- a *view* of
underlying data, which in no way modifies the data. I don't know much
about the design ideas behind SQL, but I think this view of views
(haha) is an underlying assumption. If you
On 02/24/2007 06:51:27 PM, Webb Sprague wrote:
. I have _additional_
constraints to place on modifications done through
views, and trickyness involved in modifying the
underlying tables.
Write a function foo that returns a set, then a view: "create view as
select * from foo()". Incorporate
On 02/24/2007 06:47:56 PM, Joshua D. Drake wrote:
Karl O. Pinc wrote:
>
> On 02/24/2007 06:25:54 PM, Joshua D. Drake wrote:
>
>> create your table, create your triggers on the table.
>> Use a view on top of the table for viewing (there is no such thing
as
>> a
>> select rule (well there is, but
I also think that a view is supposed to be just that -- a *view* of
underlying data, which in no way modifies the data. I don't know much
about the design ideas behind SQL, but I think this view of views
(haha) is an underlying assumption. If you are modifying data when
you do a select on a vie
. I have _additional_
constraints to place on modifications done through
views, and trickyness involved in modifying the
underlying tables.
Write a function foo that returns a set, then a view: "create view as
select * from foo()". Incorporate all the trickiness in the function,
including var
On 02/24/2007 06:25:54 PM, Joshua D. Drake wrote:
create your table, create your triggers on the table.
Use a view on top of the table for viewing (there is no such thing as
a
select rule (well there is, but it is called a view)).
Maybe you don't understand, I want to modify the
underlying ta
Karl O. Pinc wrote:
>
> On 02/24/2007 06:25:54 PM, Joshua D. Drake wrote:
>
>> create your table, create your triggers on the table.
>> Use a view on top of the table for viewing (there is no such thing as
>> a
>> select rule (well there is, but it is called a view)).
>
> Yes, and you can't put
On 02/24/2007 06:25:54 PM, Joshua D. Drake wrote:
create your table, create your triggers on the table.
Use a view on top of the table for viewing (there is no such thing as
a
select rule (well there is, but it is called a view)).
Yes, and you can't put a BEFORE EACH ROW trigger
on a view, wh
Karl O. Pinc wrote:
> Hi,
>
> I want to do some additional data validation
> when data is changed through a view, and
> I want pretty exception messages, and I want to
> do some slightly complex processing when
> determining what data to update where in
> what order.
>
> So, I figured I'd make a
Hi,
I want to do some additional data validation
when data is changed through a view, and
I want pretty exception messages, and I want to
do some slightly complex processing when
determining what data to update where in
what order.
So, I figured I'd make a table, put some
BEFORE EACH ROW trigger
20 matches
Mail list logo
