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 <robjsarg...@gmail.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.ho...@gmail.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 < > federicoemarti...@gmail.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.ho...@gmail.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 >>> >> >
