Skip site navigation (1) Skip section navigation (2)

Arrays of composites, bug or usage?

From: Chaotic Inceptions <chaoticinc(at)cyberus(dot)ca>
To: pgsql-sql(at)postgreSQL(dot)org, pgsql-bugs(at)postgreSQL(dot)org
Subject: Arrays of composites, bug or usage?
Date: 1999-11-14 21:03:04
Message-ID: 199911142103.QAA27861@cyberus.ca (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-sql
Hello,

I have a question on array usage. I created an array with the following
commands:

CREATE TABLE file (
    path                varchar(255);
    description         varchar(255);
);

CREATE TYPE file_array (
    INPUT = array_in,
    OUTPUT = array_out
    INTERNALLENGTH = VARIABLE,
    ELEMENT = file
);

CREATE TABLE media (
    media_type          char,
    media_list          file_array
);

First of all, is the above legal and if not, is there a way to do it?
Is this an array of composite types or is that something else?

When I attempt to insert values into the array with the following command, 

INSERT INTO media (media_type,media_list)
VALUES ('C', '{""/usr/doc/list1","This is the description"",
""/usr/doc/list2","Another description""}');

the INSERT succeeds, but a subsequent select reveals the following:

SELECT * FROM media;

media_type|media_list
----------+----------
C         |{0,0}
(1 row)

Is this a problem with levels of indirection in that I am looking at a
pointer or something? Have I completed the insert incorrectly or is the
parser unable to
handle this?

I would be happy to document this for everyone once I understand it.

Jason Kania
chaoticinc(at)cyberus(dot)ca


pgsql-bugs by date

Next:From: Pieter MeiringDate: 1999-11-15 10:17:35
Subject: Select acrosscross multiple tables
Previous:From: Larry RosenmanDate: 1999-11-14 19:37:08
Subject: Re: [NOVICE] createdb problem

pgsql-sql by date

Next:From: Mark StosbergDate: 1999-11-15 04:57:15
Subject: how can tell if a column is a primary key?
Previous:From: Peter EisentrautDate: 1999-11-14 18:44:52
Subject: Re: [SQL] Verificate values in other table?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group