Skip site navigation (1) Skip section navigation (2)

Re: Simplifying unknown-literal handling

From: Alvaro Herrera <alvherre(at)surnet(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simplifying unknown-literal handling
Date: 2005-05-29 17:13:55
Message-ID: 20050529171355.GA7005@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, May 29, 2005 at 11:47:18AM -0400, Tom Lane wrote:
> For the past couple of releases we've had support for cstring
> (null-terminated string) as a full fledged datatype: you set
> typlen = -2 to indicate that strlen() must be used to calculate
> the actual size of a Datum.
> 
> It occurs to me that we should change type UNKNOWN's internal
> representation to be like cstring rather than like text.  The
> advantage of this is that the places in the parser that currently
> call unknownin and unknownout could be replaced by just
> CStringGetDatum and DatumGetCString, respectively, thus saving
> two palloc's and two memcpy's per string literal.  It's not much,
> but considering that this happens every time we parse a string
> literal, I think it'll add up to a savings worth the small amount
> of effort needed.
> 
> Anyone see a reason not to change this?

Is there any way we use UNKNOWN to represent bytea literals?
Say, comparing a untyped literal to a bytea column?

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-05-29 17:19:24
Subject: Re: pg_buffercache causes assertion failure
Previous:From: Tom LaneDate: 2005-05-29 16:06:50
Subject: Small change in LockAcquire API

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group