Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
