Re: flexi adaption/casting scheme - Mailing list psycopg

From Daniele Varrazzo
Subject Re: flexi adaption/casting scheme
Date
Msg-id CA+mi_8YCjOAp_pN4SbEjq+oATD2AVdpeFzpFmV2YXk7bEFngrg@mail.gmail.com
Whole thread Raw
In response to Re: flexi adaption/casting scheme  (Tobias Oberstein <tobias.oberstein@gmail.com>)
Responses Re: flexi adaption/casting scheme
List psycopg
On Sat, Sep 22, 2012 at 2:44 PM, Tobias Oberstein
<tobias.oberstein@gmail.com> wrote:
> Am 22.09.2012 15:30, schrieb Daniele Varrazzo:
>
>> On Sat, Sep 22, 2012 at 2:25 PM, Tobias Oberstein
>> <tobias.oberstein@gmail.com> wrote:
>>
>>> the _from_db class method on CompositeCaster takes a name argument and
>>> parsed that into "schema" and "typename".
>>>
>>> It uses both to retrieve Oids etc, but then only forwards "typename", and
>>> not "schema" to the CompositeCaster constructor.
>>>
>>> If a have 2 composite types defined "public.t_foo" and "bar.t_foo", and
>>> register both, one will be overwritten ..
>>
>>
>> Uhm... why overwritten? The two CompositeCaster will register two
>> different typecasters on two different oids. The name is only used as
>
>
> Ok. So new_type/new_array_type have no issue with having the same "name"
> used twice on different OIDs?

No, none.


>> name namedtuple name. What would the schema be used for?
>
>
> My use case: have a CompositeDictCaster that spits out:
>
> {'record': 'public.t_station', 'x': 10, 'y': 8}
>
> that is injects a 'record' field containing the composite type name.
> Hence I need the schema, not only the typename.

Makes sense. I'll see to add a schema attribute to the CompositeCaster.


-- Daniele


psycopg by date:

Previous
From: Tobias Oberstein
Date:
Subject: Re: flexi adaption/casting scheme
Next
From: Tobias Oberstein
Date:
Subject: Re: flexi adaption/casting scheme