I’m quite happy using *
in audit triggers.
In that case it can actually prove a benefit because it will ensure that if additional columns are added to the base table it will raise an error so it cannot be forgotten to deal with this in the audit trigger and/or audit table structure.
(Like dotjoe) I am also happy using it in derived tables and column table expressions. Though I habitually do it the other way round.
WITH t
AS (SELECT *,
ROW_NUMBER() OVER (ORDER BY a) AS RN
FROM foo)
SELECT a,
b,
c,
RN
FROM t;
I’m mostly familiar with SQL Server and there at least the optimiser has no problem recognising that only columns a,b,c
will be required and the use of *
in the inner table expression does not cause any unnecessary overhead retrieving and discarding unneeded columns.
In principle SELECT *
ought to be fine in a view as well as it is the final SELECT
from the view where it ought to be avoided however in SQL Server this can cause problems as it stores column metadata for views which is not automatically updated when the underlying tables change and the use of *
can lead to confusing and incorrect results unless sp_refreshview
is run to update this metadata.