Re: [HACKERS] rollback varchar change

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: vadim(at)sable(dot)krasnoyarsk(dot)su (Vadim B(dot) Mikheev)
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] rollback varchar change
Date: 1998-01-08 05:07:05
Message-ID: 199801080507.AAA07928@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> Bruce Momjian wrote:
> >
> > I have found that the varchar() change I made requires a new
> > pg_attribute field, so I am rolling back the change until I get a fully
> ^^^^^^^^^^^^^^^^^^
>
> Please try some other way. As I remember, you said about breaking
> vl_len into 2 parts - very nice for me, but I'd recommend to leave
> varlena as is and add new structure - for compatibility and to allow
> text (etc) be longer 2^16 someday (multi-representation feature).
> Just like attlen -1 is used in many parts of code to flag varlena,
> you could use -2 to flag new structure.

OK, I have now figured out that my original idea was sound. The only
problem is that I started using VARSIZE in varchar.c instead of the old
vcTruelen() function. It turns out that constants have the full length
of the type with trailing nulls, and the disk data doesn't. I put the
old comparison function back, and it seems to be working just fine now.

I will look through the code some more to make sure we are safe. The
regression tests pass, so it must be working pefectly :-) The attlen
field must contain -1 so it knows it is a varlena, and just references
the real attribute length when it needs to do some creation things.

That works fine for my purposes.

--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-01-08 05:37:29 Re: [HACKERS] varchar() change
Previous Message Vadim B. Mikheev 1998-01-08 04:47:36 Re: [HACKERS] rollback varchar change