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

Re: Questionable coding in proc.c & lock.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Questionable coding in proc.c & lock.c
Date: 2000-07-28 15:59:42
Message-ID: 195.964799982@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> btw, even gram.y does touch some of the heap cache (for pg_type) to look
> for type existance; don't know if that will be a problem but maybe that
> needs to be rethought also...

We'd need to postpone that processing till parse analysis, else we still
have the underlying problem.  Fortunately we are not parsing C ;-) so
it seems to me it shouldn't be necessary to do any table lookups during
initial parsing...

I assume you are looking at the 'setof' processing?  Offhand it seems to
me that this code is broken anyway: use of a relation type should refer
to the tuple type, but should *not* imply SETOF, at least IMHO.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-07-28 16:22:37
Subject: Re: pg_dump & performance degradation
Previous:From: Bruce MomjianDate: 2000-07-28 15:51:57
Subject: Re: Questionable coding in proc.c & lock.c

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