| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | Hannu Krosing <hannu(at)skype(dot)net> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: effective SELECT from child tables |
| Date: | 2005-10-02 21:05:28 |
| Message-ID: | 20051002210528.GL30492@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Oct 02, 2005 at 11:51:27PM +0300, Hannu Krosing wrote:
> Right. Actually the "default" value returned for missing columns should
> be different from the default for new values and should be settable only
> once, when adding the column, else issues would become really really
> weird.
Right, the only way I could really imagine it working is have a flag,
attautodefault which if set would return the default instead of NULL.
It would only ever be set if the ADD COLUMN SET DEFAULT happened
together. But does this mean you have one magic default fixed for the
life of the column and the actual default which can be changed anytime?
Seems messy, though possible...
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fredrik Olsson | 2005-10-02 21:37:42 | Inherited indexes. |
| Previous Message | Hannu Krosing | 2005-10-02 20:51:27 | Re: effective SELECT from child tables |