From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marco Baringer <mb(at)bese(dot)it> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: getting domain information from query results |
Date: | 2014-01-09 16:25:36 |
Message-ID: | 5005.1389284736@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Marco Baringer <mb(at)bese(dot)it> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Day, David | 2014-01-09 16:51:20 | pg_restore - selective restore use cases. HINT use DROP CASCADE |
Previous Message | George Weaver | 2014-01-09 16:02:35 | Re: argument of CASE/WHEN must not return a set |