Are post, page and category IDs unique to each other?

Question

I was looking for a function to get all ancestors of a post or category and found get_ancestors( $object_id, $object_type ). To my surprise, the Codex shows that the second parameter is required:

$object_type
        (string) (required) The name of the object type (page, hierarchical post type, category, or hierarchical taxonomy) in question

    Default: None 

Aren't post, page and category IDs all unique to each other, i.e. the intersection of their sets would be empty?

If not, why not? It only seems to complicate an API if you have to specify the object type given that posts, pages, and categories are all data objects of a single CMS.

Answer 1

There are multiple types of data objects:

• posts: pages, regular posts, nav menu items, attachments and custom post types
• terms for different taxonomies: categories, tags, nav menus
• comments
• links
• options
• various meta data

Term ids are for a different type of objects than post ids. Both are primary keys for different tables. From Potential roadmap for taxonomy meta and post relationships:

At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3.

get_ancestors() is one of those functions that are Doing Too Much™. If you want just post (page, attachment) ancestors, use get_post_ancestors($object_id).

If not, why not? It only seems to complicate an API if you have to specify the object type given that posts, pages, and categories are all data objects of a single CMS.

The specific date for these objects are very different. If you look at the posts table, you will see many fields which aren’t needed for terms, plus revisions, drafts etc. Keeping those in different tables makes it easier to create efficient table indexes, even custom indexes, depending on your actual usage of WordPress.