Re: getting domain information from query results

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

In response to

Browse pgsql-general by date

  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