From: | <btober(at)seaworthysys(dot)com> |
---|---|
To: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <dev(at)archonet(dot)com>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Column defaults fail with rules on view |
Date: | 2003-09-19 15:51:30 |
Message-ID: | 65122.216.238.112.88.1063986690.squirrel@$HOSTNAME |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Richard Huxton <dev(at)archonet(dot)com> writes:
>> On Friday 19 September 2003 09:00, btober(at)seaworthysys(dot)com wrote:
>>> Is this supposed to work that way? I would expect field3 and field4
>>> to have their respective column defaults assigned on the second
>>> INSERT (row B), just like on the first INSERT (row A).
>
>> Hmm - well, you're explicitly telling it to insert VALUES (...,
>> new.field3, ...) so if new.field3 is null then it *should* do that.
>
> Exactly. The defaults attached to the underlying table determine what
> gets added to an INSERT into the underlying table. In this case, since
> the rule's INSERT specifies all the fields, there is no scope for those
> defaults to apply.
>
> What Berend actually wants is to attach column defaults to the *view*,
> so that they apply to an INSERT mentioning the view. You can do this
> in recent PG releases (7.3 for sure, not sure about 7.2) using ALTER
> TABLE ... ADD DEFAULT.
Now THAT's WAY cool! I can do ALTER TABLE ...ADD DEFAULT against views?
Sounds like exactly the ticket. Just tried it. It works.
That is SO sweet...the more I learn about pg the more excited I get.
~Berend Tober
From | Date | Subject | |
---|---|---|---|
Next Message | btober | 2003-09-19 15:53:26 | Re: Column defaults fail with rules on view |
Previous Message | scott.marlowe | 2003-09-19 15:49:32 | Re: Rockets (was Re: PostgreSQL versus MySQL) |