Re: [HACKERS] Progress on char(n) default-value problem

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(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:09:52
Message-ID: 199905140109.VAA18430@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> But the tuple readout routines will assume without looking that char(5)
> occupies 9 bytes altogether, so they pick up the bool field 2 bytes over
> from where it actually was put and pick up the int4 field 4 bytes over
> from where it should be (due to alignment); result is garbage. If there
> were another varlena field after the char(n) field, they'd pick up a
> wrong field length and probably crash.
>
>
> So, the question still remains "where and why"? My guess at this point
> is that this is a bad side-effect of the fact that text and char(n) are
> considered binary-equivalent. Probably, whatever bit of code ought to
> be coercing the default value into the correct type for the column is
> deciding that it doesn't have to do anything because they're already
> equivalent types. I'm not sure where to look for that code (help
> anyone?). But I am sure that it needs to be coercing the value to the
> specified number of characters for char(n).

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. Not sure if default was added before or after my
optimization.

> It also strikes me that there should be a check in the low-level
> tuple construction routines that what they are handed for a char(n)
> field is the right length. If tuple readout is going to assume that
> char(n) is always n bytes of data, good software engineering dictates
> that the tuple-writing code ought to enforce that assumption. At
> the very least there should be an Assert() for it.

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.

BTW, I couldn't find the default stuffing code myself either.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-05-14 01:22:22 Re: [HACKERS] Some progress on INSERT/SELECT/GROUP BY bugs
Previous Message Tatsuo Ishii 1999-05-14 00:58:16 Re: [HACKERS] Report on NetBSD/mac port of Postgres 6.4.2