*
* Given a relation schema (list of ColumnDef nodes), build a TupleDesc.
*
- * Note: the default assumption is no OIDs; caller may modify the returned
- * TupleDesc if it wants OIDs. Also, tdtypeid will need to be filled in
- * later on.
+ * Note: tdtypeid will need to be filled in later on.
*/
TupleDesc
BuildDescForRelation(List *schema)
continue;
/*
- * If we change column data types or add/remove OIDs, the operation
- * has to be propagated to tables that use this table's rowtype as a
- * column type. tab->newvals will also be non-NULL in the case where
- * we're adding a column with a default. We choose to forbid that
- * case as well, since composite types might eventually support
- * defaults.
+ * If we change column data types, the operation has to be propagated
+ * to tables that use this table's rowtype as a column type.
+ * tab->newvals will also be non-NULL in the case where we're adding a
+ * column with a default. We choose to forbid that case as well,
+ * since composite types might eventually support defaults.
*
* (Eventually we'll probably need to check for composite type
* dependencies even when we're just scanning the table without a
/*
* We only need to rewrite the table if at least one column needs to
- * be recomputed, we are adding/removing the OID column, or we are
- * changing its persistence.
+ * be recomputed, or we are changing its persistence.
*
* There are two reasons for requiring a rewrite when changing
* persistence: on one hand, we need to ensure that the buffers
* to be treated separately.
*
* The several datatypes representing absolute times are all converted
- * to Timestamp, which is actually a double, and then we just use that
- * double value. Note this will give correct results even for the "special"
+ * to Timestamp, which is actually an int64, and then we promote that to
+ * a double. Note this will give correct results even for the "special"
* values of Timestamp, since those are chosen to compare correctly;
* see timestamp_cmp.
*