On Fri, Apr 7, 2017 at 8:26 PM, Euler Taveira <euler@timbira.com.br> wrote:
> 2017-04-07 13:06 GMT-03:00 Kevin Grittner <kgrittn@gmail.com>:
>>
>> ERROR: cannot drop table t1 column t1id because other objects depend on
>> it
>> DETAIL: view v1 depends on table t1 column t1id
>> HINT: Use DROP ... CASCADE to drop the dependent objects too.
>>
>> Is that comment wrong?
>
> Sort of. If you consider ALTER TABLE ... DROP COLUMN ... CASCADE, it is not
> that wrong. However, if you want to be strict, there should be a check to
> identify a table column and then hint a specific message (ALTER instead of
> DROP).
I think you missed the point -- I wasn't talking about the error
message or its associated DETAIL or HINT. I was talking about this
C comment:
> * About JOINs and dropped columns: although the parser never includes an
> * already-dropped column in a JOIN RTE's alias var list, it is possible for
> * such a list in a stored rule to include references to dropped columns.
> * (If the column is not explicitly referenced anywhere else in the query,
> * the dependency mechanism won't consider it used by the rule and so won't
> * prevent the column drop.) To support get_rte_attribute_is_dropped(), we
> * replace join alias vars that reference dropped columns with null pointers.
"If the column is not explicitly referenced anywhere else in the
query [other than JOIN conditions, as I read it], the dependency
mechanism won't consider it used by the rule and so won't prevent
the column drop."
In my example the only place the column was explicitly referenced
was in a join condition, yet the dependency was recognized and the
column drop was prevented. Am I missing something or did someone
invalidate that comment without changing it to reflect the new
reality. It would appear that, under current conditions, there is
no way to reach the code which went untested. At least, I can't see
it.
--
Kevin Grittner
