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

RE: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

From: Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-sql(at)postgreSQL(dot)org
Subject: RE: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Date: 2000-02-03 16:51:33
Message-ID: 1B3D5E532D18D311861A00600865478C70C161@exchange1.nt.maidstone.gov.uk (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-sql
As usual when replying from here, replies prefixed with PM:

-- 
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.



-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Thursday, February 03, 2000 4:26 PM
To: Chris
Cc: Bruce Momjian; pgsql-hackers(at)postgreSQL(dot)org;
pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL 

PM: [snip]

For the purpose at hand, I think it would be OK to have a
"relhaschildren" field that is set true when the first child is created
and then never changed.  If you have a table that once had children but
has none at the moment, then you pay the price of looking through
pg_inherits; but the case that we're really concerned about (a pure SQL,
no-inheritance table) would still win.

PM: Perhaps get vacuum to check for any children when it's set, and if
it finds none, it clears the flag?

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-02-03 16:52:58
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Previous:From: TaralDate: 2000-02-03 16:50:30
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

pgsql-sql by date

Next:From: Tom LaneDate: 2000-02-03 16:52:58
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
Previous:From: TaralDate: 2000-02-03 16:50:30
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

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