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: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Progress on char(n) default-value problem |
Date: | 1999-05-14 01:32:11 |
Message-ID: | 14343.926645531@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:
> Good analysis. I am sure this is a byproduct of my change in 6.? that
> allowed optimzation of char() fields by assuming they are all a fixed
> length. Of course, 99% of the time they were, so it never bit us,
> except with default.
There's nothing wrong with your optimization --- a char(n) field should
be n characters 100% of the time. It's the default-insertion code
that's busted.
> At least an Assert(). However, the tuple access routines do an
> auto-compute of column offsets on the first table access, so it never
> really looks at the tuples in between. However, an Assert should check
> that when you access a char() field, that it is really the proper
> length. Good idea.
No, I think the Assert ought to be on the output side. You might never
try to access the char(n) field itself, only the following fields;
if the attcacheoff fields are already set up when you come to the
bogus tuple, an Assert in the reading side wouldn't catch it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-05-14 07:53:39 | lmgr changed |
Previous Message | Bruce Momjian | 1999-05-14 01:22:22 | Re: [HACKERS] Some progress on INSERT/SELECT/GROUP BY bugs |