Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Do we need a 'AND NOT a.attisdropped' in there anywhere as well?
Hm, probably a good idea, although in the current state of the code
it theoretically shouldn't matter. (DROP COLUMN zeroes atttypid,
so that part of the join won't succeed. But
Do we need a 'AND NOT a.attisdropped' in there anywhere as well?
Chris
On Tue, 23 Sep 2003, Irina Sourikova wrote:
>
> Hi,
>
> I tried to use vacuumlo of posgres-7.3.4/contrib/vacuumlo and it didn't
> work
> for me until I added one line:
>
> strcat(buf, " AND c.relname <> 'vacuum_l'")
This should apply cleanly to cvs tip.
I've not changed any malloc/calloc to palloc. It looks to me that these memory
areas are for the lifetime of the backend and in the interests of not breaking
something that's not broken I left alone.
Note for anyone reading this and wanting it for tsearch-v2
Irina Sourikova <[EMAIL PROTECTED]> writes:
> I tried to use vacuumlo of posgres-7.3.4/contrib/vacuumlo and it didn't
> work
> for me until I added one line:
> strcat(buf, " AND c.relname <> 'vacuum_l'");
Hmm. This bug was patched last year in CVS tip, but apparently not in
the 7.3 bra
Hi,
I tried to use vacuumlo of posgres-7.3.4/contrib/vacuumlo and it didn't
work
for me until I added one line:
strcat(buf, " AND c.relname <> 'vacuum_l'");
after strcat(buf, "SELECT c.relname, a.attname ");
strcat(buf, "FROM pg_class c, pg_attribute a, pg_type t ");
strcat(buf
On Tuesday 23 September 2003 01:19, Mike Mascari wrote:
> Yes. I guess the lifetime of this contrib module would be short - SQL
> temporary tables that don't suffer those performance penalties would
> be the correct solution.
Not for what I was thinking of (see below).
> I think it might be usef
