Thread: Noob question about types and lists
Hi, i'm really new to postgres and have some doubts. Hope somebody could explain. Let say i have a table of "clients" and every client has a small number of addresses. (let say 3) My approch is to create a type "address" like this (simplified) CREATE TYPE address AS ( street VARCHAR(160), city INTEGER, cap INTEGER, country INTEGER (those are referring to other table) ); and then composing table client CREATE TABLE client ( id SERIAL PRIMARY KEY, name VARCHAR(80), surname VARCHAR(80), address address[3].... UNIQUE (name,surname) ); This doesn't work. I cannot create a list of types. I'm using a wrong syntax? or simply i cannot do this? Please forgive me if this is explained somewhere in the doc or in faqs,I didn't find it. Thank You Christian
xchris wrote: > CREATE TYPE address AS > ( > street VARCHAR(160), > city INTEGER, > cap INTEGER, > country INTEGER (those are referring to other table) > ); > > and then composing table client > > CREATE TABLE client > ( > id SERIAL PRIMARY KEY, > name VARCHAR(80), > surname VARCHAR(80), > address address[3] > .... > UNIQUE (name,surname) > ); > > > This doesn't work. > I cannot create a list of types. > > I'm using a wrong syntax? or simply i cannot do this? From the manuals... 8.10. Arrays PostgreSQL allows columns of a table to be defined as variable-length multidimensional arrays. Arrays of any built-in or user-defined base type can be created. (Arrays of composite types or domains are not yet supported, however.) So - you can't do this at the moment. However - I don't think you want to anyway. If you're going to use a relational database, try a relational approach! Typically, you would do something like: CREATE TABLE client (id ..., name ...) CREATE TABLE address (id ..., street ...) CREATE TABLE client_address (client_id ..., address_id ...) Then, you can add some foreign-key constraints so PG makes sure that the ID numbers in client_address are all valid. This makes it simple to get client names, client addresses or both together. HTH -- Richard Huxton Archonet Ltd
On gio, 2005-10-06 at 12:20 +0100, Richard Huxton wrote: > From the manuals... > I didn't search very well.Sorry! > > However - I don't think you want to anyway. If you're going to use a > relational database, try a relational approach! Typically, you would do > something like [cut] I wanted to use a different approch because addresses don't make any sense for other tables and because they are typically few (3,4) and i wanted to avoid making a join for this task... however.. i will use your approch. Thank you for patience and suggestion! Regards Chris
xchris wrote: > On gio, 2005-10-06 at 12:20 +0100, Richard Huxton wrote: > >> From the manuals... > > I didn't search very well.Sorry! Easy enough to miss. >>However - I don't think you want to anyway. If you're going to use a >>relational database, try a relational approach! Typically, you would do >>something like [cut] > > > I wanted to use a different approch because addresses don't make any > sense for other tables and because they are typically few (3,4) and i > wanted to avoid making a join for this task... > however.. i will use your approch. If you're using a relational DB, better get used to joins :-) -- Richard Huxton Archonet Ltd