On 10/03/12 09:15, Tom Lane wrote:
Alexander Reichstadt <lxr@xxxxxxx> writes:to find out what datatypes exist. When checking on a certain field, it returned 17 as a type, thus being a bytea. That's actually the question now, because, is it always that bytea gets oid 17 or are these assignments of type name and oid dependent on the database installation, version of pg or whatever else I might be missing?The built-in data types have hand-assigned OIDs, as depicted in src/include/catalog/pg_type.h. While those aren't quite guaranteed-frozen, we've never changed one that I can recall, and are not very likely to in the future. However, any type that's not built-in has an OID that will vary across databases. As a rule of thumb, you could assume that any OID under 10000 is hand-assigned and won't change. regards, tom lane Hmm... I once did a minor cosmetic change to a report program on a mainframe. A few weeks later a user area complained their SAS program was generating errors. Turns out they were processing the print file & my added spaces caused them grief. Admittedly, it could be argued that people should not be feeding print files into programs like that. Essentially, if people are relying on specific values, I think those values should be documented appropriately, and the associated program code should reflect possible usage elsewhere. How best to achieve that in this example, I don't know. Possibly a simple comment where the numbers are assigned plus documentation in the manual (I've a vague idea this might already have been done). I guess the main
trigger for me is the idea that they have not changed for a long
time
and unlikely to be, and similar reasoning.
P.S. Hopes no one
looks
at the cruddy code I'm writing... |
