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

Re: IntArray in c.h

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: IntArray in c.h
Date: 2009-12-31 13:07:10
Message-ID: 1262264830.31337.16.camel@fsopti579.F-Secure.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On ons, 2009-12-30 at 11:46 +0900, Hitoshi Harada wrote:
> 2009/12/30 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> > Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
> >> I found the struct IntArray defined in c.h is actually used only in
> >> execQual.c. ISTM the definition should be at least moved to the right
> >> place.
> >
> > It's a general-purpose datatype that might be used anywhere that array
> > indexing happens.  I think the fact that it's currently used only in
> > execQual is mere happenstance, and should not be "enforced" by moving
> > or removing the declaration.
> 
> I would be convinced if the struct or the logic was complex, but
> actually it is so simple that it can be replaced by primitive int
> array. Also, it seems to me that c.h is too general place to declare
> it for such purpose. Does nobody else think so?

The definition of c.h is bogus anyway.  You might think it contains
includes and defines to set up a portable C environment, which is what
the first half indeed does.

But then things like regproc, transaction ID types, IntArray, varlena,
bytea, oidvector, NameData, etc. do not belong there and should be moved
to postgres.h.


In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-12-31 14:03:31
Subject: Re: Cancelling idle in transaction state
Previous:From: Gurjeet SinghDate: 2009-12-31 13:05:23
Subject: Re-enabling SET ROLE in security definer functions

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