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

[RFC] Common object property boards

From: Kohei Kaigai <Kohei(dot)Kaigai(at)EMEA(dot)NEC(dot)COM>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, Kohei KaiGai<kaigai(at)kaigai(dot)gr(dot)jp>
Subject: [RFC] Common object property boards
Date: 2011-07-29 15:58:06
Message-ID: D0C1A1F8BF513F469926E6C71461D9EC0239E2@EX10MBX02.EU.NEC.COM (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas wrote:
| I think that get_object_namespace() needs to be rethought.  If you
| take a look at AlterObjectNamespace() and its callers, you'll notice
| that we already have, encoded in those call sites, the knowledge of
| which object types can be looked up in which system caches, and which
| columns within the resulting heap tuples will contain the schema OIDs.
|  Here, we're essentially duplicating that information in another
| place, which doesn't seem good.  I think perhaps we should create a
| big static array, each row of which would contain:
| 
| - ObjectType
| - system cache ID for OID lookups
| - system catalog table OID for scans
| - attribute number for the name attribute, where applicable (see
|   AlterObjectNamespace)
| - attribute number for the namespace attribute
| - attribute number for the owner attribute
| - ...and maybe some other properties
| 
| We could then create a function (in objectaddress.c, probably) that
| you call with an ObjectType argument, and it returns a pointer to the
| appropriate struct entry, or calls elog() if none is found.  This
| function could be used by the existing object_exists() functions in
| lieu of having its own giant switch statement, by
| AlterObjectNamespace(), and by this new consolidated DROP code.  If
| you agree with this approach, we should probably make it a separate
| patch.
| 

According to the suggestion from Robert, I'd like to see opinions about
this feature prior to its implementation.

In addition to this suggestion, I think the big static array also contains
the following items:
- Text form of the object type (e.g, "table", "function", ...)
- Function pointer of validator. It shall raise an error when relkind is
  not RELKIND_RELATION for ObjectType being OBJECT_TABLE, for example.

Does the main lookup function ought to return an entry of the big array?
If so, the definition of structure should be declared in objectaddress.h,
as follows:

  ObjectProperty get_object_property(ObjectType objtype);

In addition to the big array indexed by ObjectType, I'd like to have
a utility function that translate ObjectAddress to ObjectType.
(A part of them need syscache lookup, because pg_class contains several
 objcts types: table, view, ...)

  ObjectType get_object_type(const ObjectAddress *address);

If and when we have both of the function to reference ObjectProperty and
to translate ObjectAddress to ObjectType, it is quite easy to implement
service routines to lookup namespaceId, ownerId and others for the
supplied ObjectAddress, as follows:

  Oid get_object_namespace(const ObjectAddress *address);
  Oid get_object_ownership(const ObjectAddress *address);
  char *get_object_name(const ObjectAddress *address);
  HeapTuple get_object_tuple(const ObjectAddress *address);

And, a translation from ObjectType to type name (e.g "table", "type", ...)
is helpful to generate error messages.

  const char *get_object_type_name(ObjectType objtype);

Any comments please.

Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei(dot)kaigai(at)emea(dot)nec(dot)com>

Responses

pgsql-hackers by date

Next:From: Matt KeranenDate: 2011-07-29 16:54:32
Subject: Re: OT: OFF TOPIC: returning multiple result sets from a stored procedure
Previous:From: Tom LaneDate: 2011-07-29 15:32:15
Subject: Re: error: could not find pg_class tuple for index 2662

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