On Sat, 7 Jul 2001, Rod Taylor wrote:
> This would be a potential feature of being able to insert into views
> in general. Reversing the CREATE VIEW statement to accept inserts,
> deletes and updates.
Definitely not a 'potential' feature, but a existing and documented one.
Read up on rules, especially 'ON INSERT DO INSTEAD' stuff. Its not
> If true, focus on that. Theres lots of views that cannot be reversed
> properly -- unions come to mind -- but perhaps this type of simple
> join could be a first step in the package. I believe this is on the
> TODO list already.
On TODO list are updatable views in SQL sense of word, [i.e. automatic
updateability of a view which matches certain criteria].
> Different attack, but accomplishes the same thing within SQL standards
> as I seem to recall views are supposed to do this where reasonable.
> Failing that, implement this type of action the same way as foreign
> keys. Via the described method with automagically created views,
> tables, etc. Though I suggest leaving it in contrib for sometime.
> Enum functionality isn't particularly useful to the majority whose
> applications tend to pull out the numbers for states when the
> application is opened (with the assumption they're generally static).
Original suggestion was not for an enum type, it was for _dynamically
extensible_ data dictionary type.
ENUM is statically defined, and it wouldn't be too hard to implement, with
one exception: one more type-specific field needs to be added to
pg_attribute table, where would be stored argument for the type (such as,
length for a char/varchar types, length/precision for numeric type, and
possible values for a enum type).
This just needs a pronouncement that this addition is a good idea, and
then its a trivial thing to implement enum.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-07-08 03:44:21|
|Subject: Re: Async PQgetResult() question. |
|Previous:||From: Rod Taylor||Date: 2001-07-08 02:59:41|
|Subject: Re: New SQL Datatype RECURRINGCHAR|