Tom Lane <tgl@sss.pgh.pa.us> wrote:
> BTW this seems pretty far off-topic for pgsql-performance.
It is once you understand what's happening. It was probably the 11+
minutes for the mistyped query run, versus the 28 ms without the
typo, that led them to this list.
I remembered this as an issued that has come up before, but couldn't
come up with good search criteria for finding the old thread before
you posted. If you happen to have a reference or search criteria
for a previous thread, could you post it? Otherwise, a brief
explanation of why this is considered a feature worth keeping would
be good. I know it has been explained before, but it just looks
wrong, on the face of it.
Playing around with it a little, it seems like a rather annoying
foot-gun which could confuse people and burn a lot of development
time:
test=# create domain make text;
CREATE DOMAIN
test=# create domain model text;
CREATE DOMAIN
test=# create table vehicle (id int primary key, make make);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"vehicle_pkey" for table "vehicle"
CREATE TABLE
test=# insert into vehicle values (1,
'Toyota'),(2,'Ford'),(3,'Rambler');
INSERT 0 3
test=# select v.make, v.model from vehicle v;
make | model
---------+-------------
Toyota | (1,Toyota)
Ford | (2,Ford)
Rambler | (3,Rambler)
(3 rows)
If someone incorrectly thinks they've added a column, and the
purported column name happens to match any character-based type or
domain name, they can get a query which behaves in a rather
unexpected way. In this simple query it's pretty easy to spot, but
it could surface in a much more complex query. If a mistyped query
runs for 11 days instead of 11 minutes, they may have a hard time
spotting the problem.
A typo like this could be particularly hazardous in a DELETE or
UPDATE statement.
-Kevin