From: | Peter Galbavy <Peter(dot)Galbavy(at)knowledge(dot)com> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Vadim Mikheev <vadim(at)krs(dot)ru>, Don Baccus <dhogaza(at)pacifier(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Priorities for 6.6 |
Date: | 1999-06-04 11:56:46 |
Message-ID: | 19990604125646.A24483@office.knowledge.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 03, 1999 at 11:27:14PM -0400, Bruce Momjian wrote:
> > Implementation seems easy:
> >
> > struct varlena
> > {
> > int32 vl_len;
> > char vl_dat[1];
> > };
> >
> > 1. make vl_len uint32;
> > 2. use vl_len & 0x80000000 as flag that underlying data is
> > in another place;
> > 3. put oid of external "relation" (where data is stored),
> > blocknumber and item position (something else?) to vl_dat.
> > ...
>
> Yes, it would be very nice to have this.
I hate to be fussy - normally I am just watching, but could we
*please* keep any flag like above in another field. That way, when
the size of an object reaches 2^31 we will not have legacy problems..
struct varlena
{
size_t vl_len;
int vl_flags;
caddr_t vl_dat[1];
};
(Please:)
Regards,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Griesel | 1999-06-04 12:17:42 | inet data types & select |
Previous Message | Trever Adams | 1999-06-04 10:33:31 | Re: [HACKERS] Backend sent 0x45 type while idle |