ljb wrote:
>
> pgman@candle.pha.pa.us wrote:
> >
> > The SQL standard required the change.
>
> Can you be more specific? Are we talking about SQL-99 or something beyond
> SQL-92? Of course PostgreSQL doesn't fully comply with that standard
> (whichever standard it is), so what criteria are used to determine what
> parts to comply with? Of course I would prefer selective compliance to pick
> features rather than restrictions.
SQL92 and SQL99. The criteria we typically use to choose compliance are:
1) If it is a new feature, we try to comply. Unless it is just too
stupid to do so, or if it keeps us from doing other important things.
2) If it is an existing feature, we try to comply. Unless it is beyond
the scope of the standard, if it breaks other features, or if the
standard is just too stupid to be believed.
> Sorry for the attitude here, but this change did cost me some time to fix
> applications which broke at 7.2 because of this, and I didn't enjoy that.
> I don't have access to a lot of different databases, but two I tried do
> silent truncation into CHAR and VARCHAR. I wonder what Oracle does.
We had discussions about this, and the change was motivated by a
complaint that we did things differently from someone else (I think
Oracle). Standards compliance was the tie-breaker. Check the -hackers
archives for the discussion...
It is not out of the question to make this a configurable parameter in
the GUC style. Patches would probably have a good chance of being
accepted, but I'm just guessing on that.
- Thomas