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

Re: BUG #1671: Long interval string representation rejected

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Dilger <markdilger(at)yahoo(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1671: Long interval string representation rejected
Date: 2005-05-19 01:55:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Tom Lane wrote:
> There are a lot of fixed-size local buffers in that code.  The ones
> used in output routines seem defensible since the string to be generated
> is predictable.  The ones that are used for processing input are likely
> wrong.  OTOH I'm not eager to throw a palloc into each of those code
> paths ... can we avoid that?

I'm not sure offhand what the upper bounds on legal input for each of 
the datetime types is. Why not just allocate a larger but still 
fixed-size buffer -- say, 256 bytes?

(While we're on the subject, it seems rather silly for ParseDateTime() 
not to do its own bounds checking -- all of its call sites do a strlen() 
on the input buffer before calling it, which could be avoided if 
ParseDateTime() we passed the size of `lowstr')


In response to


pgsql-bugs by date

Next:From: Neil ConwayDate: 2005-05-19 01:58:11
Subject: Re: Fw: Error when install
Previous:From: Mohan, RossDate: 2005-05-19 00:22:33
Subject: Re: [PORTS] Bug Report with Postgres 7.4 on AIX 5.3

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