[GENERAL] Relative ordering in array aggregation

[prakashn]

I'm using 8.3.3.  I came across the array_accum aggregate function in
the docs:

http://www.postgresql.org/docs/8.3/interactive/xaggr.html

CREATE AGGREGATE array_accum (anyelement)
(
sfunc = array_append,
stype = anyarray,
initcond = '{}'
);


This would be very useful to me, but I have a question about ordering
of values.  If I use more than one array_accum in the same select
clause, is there any reliable correspondence between the order of
elements in the returned arrays?  In other words, if a have a table
foo like so:

   abc
 ++
 aaa | 12 | a1
 aaa | 13 | a2

and I run

 select a, array_accum (b), array_accum (c) from foo group by a;

then can I expect that the results will always be one of
 aaa | {12, 13} | {a1, a2}
or
 aaa | {13, 12} | {a2, a1}?


OR, could the query also return the arrays as
 aaa | {13, 12} | {a1, a2}
or
 aaa | {12, 13} | {a2, a1}?

If so, would there be any way to enforce the first behaviour?

Thanks,

nishad


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Running multiple versions

[prakashn]

>
> So assuming all this is done in regular userland. built from source
> etc, you'll need to do a couple things.  Each version needs to be
> built with a different --prefix.  I prefer something like
> --prefix=/home/myusername/pg83 and --prefix=/home/myusername/pg91 and
> so on.  This will put the bin, lib etc stuff in your home dir.  Then
> in order to do work in one setup or the other, make a you'll need to
> set LD_LIBRARY_PATH and PGDATA accordingly for each instance.

Thanks for your reply, Scott.  Your suggestion sounds like it would be
fine, but I have a few more questions now.  The docs at
http://www.postgresql.org/docs/9.1/interactive/upgrading.html recommend
using the new version's pg_dumpall to back up the existing cluster for
reload.  In light of your reply, it seems you pretty much *have* to change
the pg superuser's LD_LIBRARY_PATH first.  If that's the case, it seems
the docs should mention that you need to do this, as it's somewhat
non-obvious.

Also, I have root access, so if there's a better solution outside of
regular user land, I'd like to know it.

Finally, the installation docs
(http://www.postgresql.org/docs/9.1/interactive/install-procedure.html)
mention "relocatable installs" and --disable-rpath.  Would *that* be a way
to configure the new version so that calling its .../bin/pg_dumpall (and
other things in bin) would just magically use the right .../lib/
directory?

Thanks,

nishad



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general