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

Re: Interface for pg_autovacuum

From: "Jim Nasby" <jim(dot)nasby(at)enterprisedb(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Interface for pg_autovacuum
Date: 2006-12-20 14:47:38
Message-ID: 9B73660E-DD57-4147-A995-0B83910B6697@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Dec 20, 2006, at 7:56 AM, Florian G. Pflug wrote:
> Jim Nasby wrote:
>> I'm teaching a class this week and a student asked me about OIDs.  
>> He related the story of how in Sybase, if you moved a database  
>> from one server from another, permissions got all screwed up  
>> because user IDs no longer matched. I explained that exposing  
>> something like an integer ID in a user interface or an API is just  
>> a bad idea and PostgreSQL doesn't do that.
>> Then I got to pg_autovacuum....
>> So... is there any reason there isn't a prescribed interface to  
>> pg_autovacuum that doesn't expose vacrelid? Can we get that added  
>> to TODO?
>
> Wouldn't it be sufficient to change the type of vacrelid from oid
> to regclass? Then just dumping and restoring pg_autovacuum like any
> other table should Just Work.

I think that would work, though as I mentioned we'd also want to set  
reasonable defaults on the table if we decide to keep that as our  
interface.

On the other hand, this would be the only part of the system where  
the official interface/API is a system catalog table. Do we really  
want to expose the internal representation of something as our API?  
That doesn't seem wise to me...

Additionally, AFAIK it is not safe to go poking data into catalogs  
willy-nilly. Having one table where this is the interface to the  
system seems like it could lead to some dangerous confusion.
--
Jim Nasby                               jim(dot)nasby(at)enterprisedb(dot)com
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2006-12-20 14:49:32
Subject: Re: [HACKERS] Enums patch v2
Previous:From: Tom LaneDate: 2006-12-20 14:46:30
Subject: Re: [HACKERS] Bundle of patches

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