473,836 Members | 1,553 Online

# join of array

Hello,

Is possible merge two arrays like

array[1,2,3] + array[4,5,6] => array[1,2,3,4,5,6]

select array_append(ar ray[1,2,3], array[2,3]);
ERROR: function array_append(in teger[], integer[]) does not exist
regards
Pavel Stehule
TIP 8: explain analyze is your friend

Nov 11 '05
20 4727
Tom Lane wrote:
I believe the behavior Elein wants can be had by writing
ARRAY[ n_d_array , n_d_array ]
(Joe, would you confirm that's true, and document it? I don't think
either section 8.10 or section 4.2.8 makes clear that you can build
arrays from smaller array values rather than just scalars.) As long as
we have that alternative, it's not necessary that concatenation do the
same thing.

Well this works:
regression=# select ARRAY[ARRAY[[1,2],[3,4]],ARRAY[[5,6],[7,8]]];
array
-------------------------------
{{{1,2},{3,4}}, {{5,6},{7,8}}}
(1 row)
But I was disappointed that this doesn't:

regression=# select ARRAY['{{1,2},{3,4}}' ::int[],'{{5,6},{7,8}} '::int[]];
ERROR: multidimensiona l ARRAY[] must be built from nested array expressions

Nor does this:

create table arr(f1 int[], f2 int[]);
insert into arr values (ARRAY[[1,2],[3,4]],ARRAY[[5,6],[7,8]]);
regression=# select ARRAY[f1,f2] from arr;
ERROR: multidimensiona l ARRAY[] must be built from nested array expressions

It does work for the element to array case:

create table els(f1 int, f2 int);
insert into els values (1,2);
regression=# select ARRAY[f1,f2] from els;
array
-------
{1,2}
(1 row)
Should I try to make the second and third cases work?

Joe
TIP 8: explain analyze is your friend

Nov 11 '05 #11
Joe Conway <ma**@joeconway .com> writes:
But I was disappointed that this doesn't: regression=# select ARRAY['{{1,2},{3,4}}' ::int[],'{{5,6},{7,8}} '::int[]];
ERROR: multidimensiona l ARRAY[] must be built from nested array expressions
Drat, I was assuming that that *would* work.
Should I try to make the second and third cases work?

Could you look at how big a change it'd be, anyway? Offhand I think it
may just mean that the subscript-checking done in parse_expr.c needs to
be done at runtime instead. Remember parse_expr should only be
concerned about determining datatype, and for its purposes all arrays of
a given element type are the same --- subscript checking should happen
at runtime. (It seems likely that having an ndims field in ArrayExpr
is inappropriate.)

regards, tom lane

TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

Nov 11 '05 #12
Hi,

Tom Lane wrote:
Joe Conway <ma**@joeconway .com> writes:
But I was disappointed that this doesn't:

regression= # select ARRAY['{{1,2},{3,4}}' ::int[],'{{5,6},{7,8}} '::int[]];
ERROR: multidimensiona l ARRAY[] must be built from nested array expressions

Drat, I was assuming that that *would* work.

Should I try to make the second and third cases work?

Could you look at how big a change it'd be, anyway? Offhand I think it
may just mean that the subscript-checking done in parse_expr.c needs to
be done at runtime instead. Remember parse_expr should only be
concerned about determining datatype, and for its purposes all arrays of
a given element type are the same --- subscript checking should happen
at runtime. (It seems likely that having an ndims field in ArrayExpr
is inappropriate.)

Wouldn't it be a good idea to just extend the partner arrays? Say
if we concenate array A(Na,..,Xa) || B(Nb,...,Xb)
The resulting array C would be of dimension
C(Na+Nb,max(Oa, Ob),max(Pa,Pb), ... max(Xa,Xb))
So concenation would be an extending and right hand appending (at first
level)

Regards
Tino Wildenhain

subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #13
On Fri, 2003-08-15 at 13:32, elein wrote:
PostgreSQL is an ORDBMS, not just an RDBMS.
But y'all are talking about the SQL standard here.
A column holds a type of value. Any kind. The
structure and operands define the type. The data
defines the value. This holds true for simple types
like an integer or complex types like an array.

The database data is relatively "type blind" in an
ORDBMS. It uses the standard overloaded operands
to determine the type of function to perform for
all of the usual RDBMS utilities.
Constraints, triggers, sorting, etc. all apply.

That's what the ORDBMS stuff can give you.
Arrays are a natural extension.

Arrays don't necessarily imply denormalization .
It depends on how you use them. The same rule
applies for integers.
I dunno 'bout that...
elein

On Fri, Aug 15, 2003 at 01:13:52PM -0500, Ron Johnson wrote:

Why are arrays even mentioned in the the same breath wrt relations
DBMSs? Aren't they an anathema to all we know and love?

--
+---------------------------------------------------------------+
| Ron Johnson, Jr. Home: ro***********@c ox.net |
| Jefferson, LA USA |
| |
| "Man, I'm pretty. Hoo Hah!" |
| Johnny Bravo |
+---------------------------------------------------------------+

TIP 8: explain analyze is your friend

Nov 11 '05 #14
In response to both Andrew Gould and Ron Johnson...

If arrays are not natural in the organization of
your data, don't use them. That is the guideline.

If the array defines something specific they are
very natural. The confusion could be that arrays
are abstract types.

Specific implementations which use arrays might
be clearer. For example, a definition of a polygon
is an array of Points. Points, themselves are an
array.

(The actual postgreSQL implementation of polygons and points
doesn't use the newer cleaner array abstraction, I think.
But if I were reimplementing them, I would build on
top of the new array capabilities. The point is to show
an array structured object which makes sense in context.)

Of course you can denomalize via arrays, but it tends
to make things harder for you. And I believe the
same thing is true for denormalized integer columns.

elein
=============== =============== =============== =============== =
el***@varlena.c om www.varlena.com
PostgreSQL Consulting & Support
PostgreSQL General Bits http://www.varlena.com/GeneralBits/
=============== =============== =============== =============== =
"Free your mind the rest will follow"
-- En Vogue
On Fri, Aug 15, 2003 at 02:20:18PM -0500, Ron Johnson wrote:
On Fri, 2003-08-15 at 13:32, elein wrote:
PostgreSQL is an ORDBMS, not just an RDBMS.

But y'all are talking about the SQL standard here.
A column holds a type of value. Any kind. The
structure and operands define the type. The data
defines the value. This holds true for simple types
like an integer or complex types like an array.

The database data is relatively "type blind" in an
ORDBMS. It uses the standard overloaded operands
to determine the type of function to perform for
all of the usual RDBMS utilities.
Constraints, triggers, sorting, etc. all apply.

That's what the ORDBMS stuff can give you.
Arrays are a natural extension.

Arrays don't necessarily imply denormalization .
It depends on how you use them. The same rule
applies for integers.

I dunno 'bout that...
elein

On Fri, Aug 15, 2003 at 01:13:52PM -0500, Ron Johnson wrote:

Why are arrays even mentioned in the the same breath wrt relations
DBMSs? Aren't they an anathema to all we know and love?

--
+---------------------------------------------------------------+
| Ron Johnson, Jr. Home: ro***********@c ox.net |
| Jefferson, LA USA |
| |
| "Man, I'm pretty. Hoo Hah!" |
| Johnny Bravo |
+---------------------------------------------------------------+

TIP 8: explain analyze is your friend

TIP 7: don't forget to increase your free space map settings

Nov 11 '05 #15
On Friday 15 August 2003 02:56 pm, elein wrote:
In response to both Andrew Gould and Ron Johnson...

If arrays are not natural in the organization of
your data, don't use them. That is the guideline.

If the array defines something specific they are
very natural. The confusion could be that arrays
are abstract types.

Specific implementations which use arrays might
be clearer. For example, a definition of a polygon
is an array of Points. Points, themselves are an
array.

(The actual postgreSQL implementation of polygons and points
doesn't use the newer cleaner array abstraction, I think.
But if I were reimplementing them, I would build on
top of the new array capabilities. The point is to show
an array structured object which makes sense in context.)

Of course you can denomalize via arrays, but it tends
to make things harder for you. And I believe the
same thing is true for denormalized integer columns.

elein
=============== =============== =============== =============== =
el***@varlena.c om www.varlena.com

Thanks, Elein. The polygon example makes it clearer. In the books I have
here, the examples show how to use arrays but they use data that I would move
to another table.

Best regards,

Andrew

subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #16
On Fri, 2003-08-15 at 15:36, Andrew L. Gould wrote:
On Friday 15 August 2003 02:56 pm, elein wrote:
In response to both Andrew Gould and Ron Johnson...

If arrays are not natural in the organization of
your data, don't use them. That is the guideline.

If the array defines something specific they are
very natural. The confusion could be that arrays
are abstract types.

Specific implementations which use arrays might
be clearer. For example, a definition of a polygon
is an array of Points. Points, themselves are an
array.

(The actual postgreSQL implementation of polygons and points
doesn't use the newer cleaner array abstraction, I think.
But if I were reimplementing them, I would build on
top of the new array capabilities. The point is to show
an array structured object which makes sense in context.)

Of course you can denomalize via arrays, but it tends
to make things harder for you. And I believe the
same thing is true for denormalized integer columns.

elein
=============== =============== =============== =============== =
el***@varlena.c om www.varlena.com

Thanks, Elein. The polygon example makes it clearer. In the books I have
here, the examples show how to use arrays but they use data that I would move
to another table.

This is what makes me nervous about db arrays: the tendency for
denormalization .

--
+---------------------------------------------------------------+
| Ron Johnson, Jr. Home: ro***********@c ox.net |
| Jefferson, LA USA |
| |
| "Man, I'm pretty. Hoo Hah!" |
| Johnny Bravo |
+---------------------------------------------------------------+

TIP 4: Don't 'kill -9' the postmaster

Nov 11 '05 #17
create table import_contact (
id character(7) not null primary key,
fm character(30),
ls character(30),
city character(25),
st character(2),
c character(1),
start decimal(6),
end decimal(6),
) WITHOUT OIDS;

cat datafile.dat | psql -dthedatabase -c "copy import_contact from stdin
delimiter ',' null ''";

echo "insert into contact select
id,
case fm when null then 'xzxzxzxz' else fm end,
case ls when null then 'xzxzxzxz' else ls end,
case city when null then 'xzxzxzxz' else city end,
case st when null then 'xz' else st end,
case c when null then 'x' else c end,
case start when null then 122038 else start,
case end when null then 122038 else end
from import_contact; " | psql -dthedatabase

Could be one way although it's not atomic. Can rewrite the copy command to be
a copy from file command to do that and use the \i command (or redirect to
psql from file/stdin). Simple but there are many other methods to get this
thing to work. If you don't want to recreate the defaults everytime then you
could have subselects that reference the pg system tables extract the default
value for the columns you are looking for.

Also could create the insert statements with a script on the outside or
replace any blank (null in reality) fields with the default value and copy
that straight to the table.

On Sat, 16 Aug 2003 03:18 am, expect wrote:
I'd like to summarize what I know (or don't know) since this topic has been
hit around a little and I'm new to this. I'm hoping it will clear things
up, at least for me. You are all the experts, I want to make sure I am
singing from the same page.

data sample:
id | fm | ls | addr | city | st | z |c|
start|end
---------------------------------------------------------------------------
-------

191922C,Bob Cobb,D'Obbalina Sr.,312 Elm
Street,Yountvil le,CA,94599,5,0 62001,082009 339111C,Elma Thelma,Velma,98 Oak
Lane,St. Louis,MO,63119-2065,,,
What I wanted to do was to import lots of these from a text file. In the
case where there is an empty string (i.e. no value after a comma) I wanted
to define the column in the table in a way that would accept the empty
string but replace it with the default value for that column. I didn't
know that the copy command is just some C code that stuffs the data into
the db ala fois grois.

What I would really benefit from (and I hope some other new soul would too)
is if someone would outline exactly how they would approach this problem.

Maybe provide the correct table definition and the copy command. Or if
that just won't work an alternate approach. I realize that some of you
have done this partially but there have been too many replies to get into a
single cohesive instruction.
Anyway I suppose my initial frustration in trying to do this may have
blinded me from reason.
create table contact (
id character(7) NOT NULL,
fm character(30) DEFAULT 'xzxzxzxz',
ls character(30) DEFAULT 'xzxzxzxz',
city character(25) DEFAULT 'xzxzxzxz',
st character(2) DEFAULT 'xz',
c character(1) DEFAULT 'x',
start decimal(6) DEFAULT 122038,
end decimal(6) DEFAULT 122038,
CONSTRAINT handle PRIMARY KEY (id)
) WITHOUT OIDS;
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 11 '05 #18
On Sat, 16 Aug 2003 09:33:51 +1000
Jason Godden <ja*********@op tushome.com.au> wrote:
Ahh, thanks for this. And thanks to all the others that helped me on my way.
Hopefully I'll be able to give something back to the group. Although that
might be hard with all the experts here.

Perhaps I can document this and provide it for public consumption.

create table import_contact (
id character(7) not null primary key,
fm character(30),
ls character(30),
city character(25),
st character(2),
c character(1),
start decimal(6),
end decimal(6),
) WITHOUT OIDS;

cat datafile.dat | psql -dthedatabase -c "copy import_contact from stdin
delimiter ',' null ''";

echo "insert into contact select
id,
case fm when null then 'xzxzxzxz' else fm end,
case ls when null then 'xzxzxzxz' else ls end,
case city when null then 'xzxzxzxz' else city end,
case st when null then 'xz' else st end,
case c when null then 'x' else c end,
case start when null then 122038 else start,
case end when null then 122038 else end
from import_contact; " | psql -dthedatabase

Could be one way although it's not atomic. Can rewrite the copy command to be
a copy from file command to do that and use the \i command (or redirect to
psql from file/stdin). Simple but there are many other methods to get this
thing to work. If you don't want to recreate the defaults everytime then you
could have subselects that reference the pg system tables extract the default
value for the columns you are looking for.

Also could create the insert statements with a script on the outside or
replace any blank (null in reality) fields with the default value and copy
that straight to the table.

On Sat, 16 Aug 2003 03:18 am, expect wrote:
I'd like to summarize what I know (or don't know) since this topic has been
hit around a little and I'm new to this. I'm hoping it will clear things
up, at least for me. You are all the experts, I want to make sure I am
singing from the same page.

data sample:
id | fm | ls | addr | city | st | z |c|
start|end
---------------------------------------------------------------------------
-------

191922C,Bob Cobb,D'Obbalina Sr.,312 Elm
Street,Yountvil le,CA,94599,5,0 62001,082009 339111C,Elma Thelma,Velma,98 Oak
Lane,St. Louis,MO,63119-2065,,,
What I wanted to do was to import lots of these from a text file. In the
case where there is an empty string (i.e. no value after a comma) I wanted
to define the column in the table in a way that would accept the empty
string but replace it with the default value for that column. I didn't
know that the copy command is just some C code that stuffs the data into
the db ala fois grois.

What I would really benefit from (and I hope some other new soul would too)
is if someone would outline exactly how they would approach this problem.

Maybe provide the correct table definition and the copy command. Or if
that just won't work an alternate approach. I realize that some of you
have done this partially but there have been too many replies to get into a
single cohesive instruction.
Anyway I suppose my initial frustration in trying to do this may have
blinded me from reason.
create table contact (
id character(7) NOT NULL,
fm character(30) DEFAULT 'xzxzxzxz',
ls character(30) DEFAULT 'xzxzxzxz',
city character(25) DEFAULT 'xzxzxzxz',
st character(2) DEFAULT 'xz',
c character(1) DEFAULT 'x',
start decimal(6) DEFAULT 122038,
end decimal(6) DEFAULT 122038,
CONSTRAINT handle PRIMARY KEY (id)
) WITHOUT OIDS;
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

TIP 6: Have you searched our list archives?

http://archives.postgresql.org

subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #19
Just a note on that example:

I didn't properly end the case commands on the last two fields in the insert
and end should probably be quoted. No I haven't tested it. Should be:

echo "insert into contact select
id,
case fm when null then 'xzxzxzxz' else fm end,
case ls when null then 'xzxzxzxz' else ls end,
case city when null then 'xzxzxzxz' else city end,
case st when null then 'xz' else st end,
case c when null then 'x' else c end,
case start when null then 122038 else start end,
case "end" when null then 122038 else "end" end
from import_contact; " | psql -dthedatabase

Rgds,

Jason

On Sat, 16 Aug 2003 01:10 pm, expect wrote:
On Sat, 16 Aug 2003 09:33:51 +1000
Jason Godden <ja*********@op tushome.com.au> wrote:
Ahh, thanks for this. And thanks to all the others that helped me on my
way. Hopefully I'll be able to give something back to the group. Although
that might be hard with all the experts here.

Perhaps I can document this and provide it for public consumption.
create table import_contact (
id character(7) not null primary key,
fm character(30),
ls character(30),
city character(25),
st character(2),
c character(1),
start decimal(6),
end decimal(6),
) WITHOUT OIDS;

cat datafile.dat | psql -dthedatabase -c "copy import_contact from stdin
delimiter ',' null ''";

echo "insert into contact select
id,
case fm when null then 'xzxzxzxz' else fm end,
case ls when null then 'xzxzxzxz' else ls end,
case city when null then 'xzxzxzxz' else city end,
case st when null then 'xz' else st end,
case c when null then 'x' else c end,
case start when null then 122038 else start,
case end when null then 122038 else end
from import_contact; " | psql -dthedatabase

Could be one way although it's not atomic. Can rewrite the copy command
to be a copy from file command to do that and use the \i command (or
redirect to psql from file/stdin). Simple but there are many other
methods to get this thing to work. If you don't want to recreate the
defaults everytime then you could have subselects that reference the pg
system tables extract the default value for the columns you are looking
for.

Also could create the insert statements with a script on the outside or
replace any blank (null in reality) fields with the default value and
copy that straight to the table.

On Sat, 16 Aug 2003 03:18 am, expect wrote:
I'd like to summarize what I know (or don't know) since this topic has
been hit around a little and I'm new to this. I'm hoping it will clear
things up, at least for me. You are all the experts, I want to make
sure I am singing from the same page.

data sample:
id | fm | ls | addr | city | st | z |c|
start|end
-----------------------------------------------------------------------
---- -------

191922C,Bob Cobb,D'Obbalina Sr.,312 Elm
Street,Yountvil le,CA,94599,5,0 62001,082009 339111C,Elma Thelma,Velma,98
Oak Lane,St. Louis,MO,63119-2065,,,
What I wanted to do was to import lots of these from a text file. In
the case where there is an empty string (i.e. no value after a comma)
I wanted to define the column in the table in a way that would accept
the empty string but replace it with the default value for that column.
I didn't know that the copy command is just some C code that stuffs
the data into the db ala fois grois.

What I would really benefit from (and I hope some other new soul would
too) is if someone would outline exactly how they would approach this
problem.

Maybe provide the correct table definition and the copy command. Or if
that just won't work an alternate approach. I realize that some of you
have done this partially but there have been too many replies to get
into a single cohesive instruction.
Anyway I suppose my initial frustration in trying to do this may have
blinded me from reason.
create table contact (
id character(7) NOT NULL,
fm character(30) DEFAULT 'xzxzxzxz',
ls character(30) DEFAULT 'xzxzxzxz',
city character(25) DEFAULT 'xzxzxzxz',
st character(2) DEFAULT 'xz',
c character(1) DEFAULT 'x',
start decimal(6) DEFAULT 122038,
end decimal(6) DEFAULT 122038,
CONSTRAINT handle PRIMARY KEY (id)
) WITHOUT OIDS;
---------------------------(end of
broadcast)--------------------------- TIP 2: you can get off all lists
at once with the unregister command (send "unregister

TIP 6: Have you searched our list archives?

http://archives.postgresql.org

subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 11 '05 #20

This thread has been closed and replies have been disabled. Please start a new discussion.