Marco Baringer <mb@xxxxxxx> writes: > it seems, if my understanding of the protocol is correct, that the oid > of the underlying type, text in this case, is returned and not the oid > of the domain. That's correct. This was an intentional decision long ago, and we're unlikely to reconsider now for fear of breaking applications. (IIRC, the argument was that client-side code was most likely to be concerned with matters like the textual representation of the value, and so getting told about domains would just complicate life.) > i tried creating a new type (which have solved my problem with the > "wrong" oid getting returned with the query results), but then realized > i'd have to implement all of the associated operators for my new type as > well (they'd just be cut 'n pastes of the equivalent operators for > varchar, but that's still a bit more work than i'd like to do at this > point). If you'd dug a bit more deeply, you'd have noticed that varchar doesn't *have* any operators; it relies on text's operators via an implicit cast to text. You could likely do the same for a custom string type. This answer doesn't scale to non-string data types of course, but it might be good enough for your situation. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
