Re: [HACKERS] DEFAULT fixed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] DEFAULT fixed
Date: 1999-05-22 14:45:51
Message-ID: 7378.927384351@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> Does anyone have an opinion on this? Why does only DEFAULT have this
> problem? Does anyone know how inserts of '' into char() fields get
> padded with the proper atttypmod value? Do I need to pass atttypmod to
> all the functions that call parse_coerce, so I can pass a value for all
> cases?

Possibly DEFAULT is the only case where the constant value created by
the parser will get shoved directly into a tuple with no run-time
coercion? That's strictly a guess. I agree this issue needs to be
looked at more closely.

Now that we know the problem comes from missing atttypmod info, it
seems likely that related failures can occur for NUMERIC and other
types that depend on atttypmod. (Are there any such types? Even
if there aren't now, there will probably be more and more in future.)
It might be best to just bite the bullet and make the parser carry
around both the type's OID and typmod at all times.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-22 23:48:59 Re: [HACKERS] GEQO optimizer (was Re: Backend message type 0x44 arrived while idle)
Previous Message Bruce Momjian 1999-05-22 07:10:33 Re: [HACKERS] strange behavior of UPDATE