Re: Altering array(composite-types) without breaking code when inserting them and similar questions

Because i always query the whole row, and in the other way(many tables) i
will always join + have other indexes.

On Sun, Apr 20, 2014 at 8:56 PM, Rob Sargent <robjsargent(at)gmail(dot)com> wrote:

> Why do you think you need an array of theType v. a dependent table of
> theType. This tack is of course immune to to most future type changess.
>
> Sent from my iPhone
>
> On Apr 20, 2014, at 11:57 AM, Dorian Hoxha <dorian(dot)hoxha(at)gmail(dot)com> wrote:
>
> Was just curious about the overhead.
>
> I know the columns, but i may need to add other columns in the future.
> Yeah, json is the alternative if this doesn't work.
>
>
>
> On Sun, Apr 20, 2014 at 7:54 PM, Fede Martinez <
> federicoemartinez(at)gmail(dot)com> wrote:
>
>> If you don't know the columns your type will have, you could consider
>> using json or hstore if the data is unstructured.
>> El 20/04/2014 14:04, "Dorian Hoxha" <dorian(dot)hoxha(at)gmail(dot)com> escribió:
>>
>> Hi list,
>>>
>>> I have a
>>> create type thetype(width integer, height integer);
>>> create table mytable(thetype thetype[]);
>>>
>>> How can i make an insert statement so if i later add fields to the
>>> composite type, the code/query doesn't break ?
>>> Maybe by specifying the fields of the composite type in the query ?
>>>
>>> This can be done for normal inserts(non arrays):
>>> CREATE TABLE mytable (t thetype);
>>> INSERT INTO mytable(t.width, t.height) VALUES (11,22);
>>>
>>>
>>> Also how to update an whole element of an array of composites ?
>>> Also, how to update an attribute in a specific element in an array of
>>> composites?
>>>
>>> (so when i add columns later to the composite, my old code doesn't
>>> break)
>>>
>>> How much overhead have the composite types beside the values and nulls?
>>>
>>> Thanks
>>>
>>
>