Thread: PostgreSQL Final Release ... Monday?
Morning all ... So far as we can tell, we're *finally* ready for release ... Tom made a few benign commits since rc2 that he feels doesn't warrant an rc3, so we are planning on doing the final release on Monday ... Does *anyone* have any outstanding bugs that they would like to report *before* the final release? Anything that should hold up the release even if for a couple of days? If so, please speak up now or forever hold your peace ... If not, I'm going to roll up the final release on Sunday night, and do a full announce on Monday afternoon ... Its been a *long* release cycle this time through, but nobody can accuse us of not being thorough in our testing :) Great work, and heart-felt thanks to everyone for the work that went into this release ... should prove another one to serve us well and make us proud :)
On Wed, 30 Jan 2002, Marc G. Fournier wrote: > > Morning all ... > > So far as we can tell, we're *finally* ready for release ... Tom > made a few benign commits since rc2 that he feels doesn't warrant an rc3, > so we are planning on doing the final release on Monday ... > > Does *anyone* have any outstanding bugs that they would like to > report *before* the final release? Anything that should hold up the > release even if for a couple of days? > > If so, please speak up now or forever hold your peace ... How are we set for docs? I don't recall Thomas calling for a freeze. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Wed, 30 Jan 2002, Marc G. Fournier wrote: > > Actually, talked to him about it, and he says that since we aren't doing > the hardcopy in the distribution anymore, we're fine for that too ... Perfect! > > > On Wed, 30 Jan 2002, Vince Vielhaber wrote: > > > On Wed, 30 Jan 2002, Marc G. Fournier wrote: > > > > > > > > Morning all ... > > > > > > So far as we can tell, we're *finally* ready for release ... Tom > > > made a few benign commits since rc2 that he feels doesn't warrant an rc3, > > > so we are planning on doing the final release on Monday ... > > > > > > Does *anyone* have any outstanding bugs that they would like to > > > report *before* the final release? Anything that should hold up the > > > release even if for a couple of days? > > > > > > If so, please speak up now or forever hold your peace ... > > > > How are we set for docs? I don't recall Thomas calling for a freeze. > > > > Vince. > > -- > > ========================================================================== > > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > > Online Campground Directory http://www.camping-usa.com > > Online Giftshop Superstore http://www.cloudninegifts.com > > ========================================================================== > > > > > > > > > > Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Actually, talked to him about it, and he says that since we aren't doing the hardcopy in the distribution anymore, we're fine for that too ... On Wed, 30 Jan 2002, Vince Vielhaber wrote: > On Wed, 30 Jan 2002, Marc G. Fournier wrote: > > > > > Morning all ... > > > > So far as we can tell, we're *finally* ready for release ... Tom > > made a few benign commits since rc2 that he feels doesn't warrant an rc3, > > so we are planning on doing the final release on Monday ... > > > > Does *anyone* have any outstanding bugs that they would like to > > report *before* the final release? Anything that should hold up the > > release even if for a couple of days? > > > > If so, please speak up now or forever hold your peace ... > > How are we set for docs? I don't recall Thomas calling for a freeze. > > Vince. > -- > ========================================================================== > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > Online Campground Directory http://www.camping-usa.com > Online Giftshop Superstore http://www.cloudninegifts.com > ========================================================================== > > > >
"Marc G. Fournier" wrote: > > Morning all ... > > So far as we can tell, we're *finally* ready for release ... Tom > made a few benign commits since rc2 that he feels doesn't warrant an rc3, > so we are planning on doing the final release on Monday ... > > Does *anyone* have any outstanding bugs that they would like to > report *before* the final release? Anything that should hold up the > release even if for a couple of days? > > If so, please speak up now or forever hold your peace ... > > If not, I'm going to roll up the final release on Sunday night, > and do a full announce on Monday afternoon ... > > Its been a *long* release cycle this time through, but nobody can > accuse us of not being thorough in our testing :) > > Great work, and heart-felt thanks to everyone for the work that > went into this release ... should prove another one to serve us well and > make us proud :) I submitted a "contrib" project for integer array aggregation/enumeration. I didn't see it in rc2.
> > went into this release ... should prove another one to serve us well and > > make us proud :) > > I submitted a "contrib" project for integer array > aggregation/enumeration. I didn't see it in rc2. That is being held for 7.3: This has been saved for the 7.3 release: http://candle.pha.pa.us/cgi-bin/pgpatches2 --------------------------------------------------------------------------- -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
It is used as an aggregation function. It only works on integers, and assumes sizeof(int) == sizeof(void *) There are two functions: int_array_aggregate(int4) and int_array_enum(int4[]) One creates an integer array as: create table tst as select some_field, int_array_aggregate(int_field) as field from table group by some_field; This will poduce one row for all the unique "some_fields" with an array of all "int_field" associated. To extract this, you use int_array_enum(int_array); whic returns multiple results. Hannu Krosing wrote: > > On Thu, 2002-01-31 at 02:36, mlw wrote: > > > > I submitted a "contrib" project for integer array > > aggregation/enumeration. I didn't see it in rc2. > > > > Some general questions about arrays - > > 1. Could this aggregation/enumeration be done in a generic way, so > that you could aggregate over any array ? > > The only generic function I currently know of is count(), but it > is generic only on argument side, i.e count(any) returns always > integer. > > 2. Is there a way to define a function such that > > declare make_array(any) returns any[] ? > > 3. Also, can I prescribe order of aggregation (aggregation applied > _after_ ORDER BY) that would act in a way similar to HAVING . > > 4. what arguments must I give to array_in so that it produces an > array of specific kind ? I tried some more obvious things and > really got nowhere. > > -------------- > Hannu > > PS. I attach an alpha-contrib ofPL/PgSQL code to compare intarrays. > I have not had time to tie these ops to indexes > > -------------- > Hannu > > ------------------------------------------------------------------------------- > Name: ARRAY_COMP.SQL > ARRAY_COMP.SQL Type: text/x-sql > Encoding: quoted-printable
Marc G. Fournier writes: > So far as we can tell, we're *finally* ready for release ... Tom > made a few benign commits since rc2 that he feels doesn't warrant an rc3, > so we are planning on doing the final release on Monday ... Good. I've just gone through checking that all the files that need manual updates have received them, and I've built and uploaded new man pages. The only thing that still needs to be done is setting the date top the register.txt file. Don't forget that when you're ready. -- Peter Eisentraut peter_e@gmx.net
On Thu, 2002-01-31 at 02:36, mlw wrote: > > I submitted a "contrib" project for integer array > aggregation/enumeration. I didn't see it in rc2. > Some general questions about arrays - 1. Could this aggregation/enumeration be done in a generic way, so that you could aggregate over any array ? The only generic function I currently know of is count(), but it is generic only on argument side, i.e count(any) returns always integer. 2. Is there a way to define a function such that declare make_array(any) returns any[] ? 3. Also, can I prescribe order of aggregation (aggregation applied _after_ ORDER BY) that would act in a way similar to HAVING . 4. what arguments must I give to array_in so that it produces an array of specific kind ? I tried some more obvious things and really got nowhere. -------------- Hannu PS. I attach an alpha-contrib ofPL/PgSQL code to compare intarrays. I have not had time to tie these ops to indexes -------------- Hannu
Attachment
On Wed, 2002-01-30 at 14:29, Marc G. Fournier wrote: > > Morning all ... > > So far as we can tell, we're *finally* ready for release ... Tom > made a few benign commits since rc2 that he feels doesn't warrant an rc3, > so we are planning on doing the final release on Monday ... > > Does *anyone* have any outstanding bugs that they would like to > report *before* the final release? Anything that should hold up the > release even if for a couple of days? Typo in docs, I think. user guide 4.7 should be "Date Type Formatting Functions" instead of "Data", ISTM -- Karl DeBisschop Director, Software Engineering & Development Learning Network / Information Please www.learningnetwork.com / www.infoplease.com
Karl DeBisschop <kdebisschop@range.infoplease.com> writes:
> Typo in docs, I think.
> user guide 4.7 should be "Date Type Formatting Functions" instead of
> "Data", ISTM
No, because to_number and the numeric variants of to_char are in there
too.
regards, tom lane
Hannu Krosing <hannu@krosing.net> writes:
> 2. Is there a way to define a function such that
> declare make_array(any) returns any[] ?
No. We do need a way to construct an array as an expression result,
but I think it will have to be a special syntactic case, not an ordinary
function. Maybe something roughly like a CAST construct,ARRAY(expr,expr,expr,... OF type-name)
The function definition language isn't nearly powerful enough to deal
with this --- heck, we don't even support a variable number of
arguments. If it were, it'd probably break the whole ambiguous-
function-call resolution mechanism --- what type do you assign to the
output if you're not entirely sure how the inputs are to be interpreted?
> 3. Also, can I prescribe order of aggregation (aggregation applied
> _after_ ORDER BY) that would act in a way similar to HAVING .
Sub-select in FROM might help here.
> 4. what arguments must I give to array_in so that it produces an
> array of specific kind ?
You don't. array_in is meant to be used as the declared typinput
routine for an array type; that linkage is what causes the system
to know what the output array type is. array_in by itself can't
cause the system to assign a correct type to its result.
regards, tom lane
> > Does *anyone* have any outstanding bugs that they would like to > > report *before* the final release? Anything that should hold up the > > release even if for a couple of days? > > Typo in docs, I think. > > user guide 4.7 should be "Date Type Formatting Functions" instead of > "Data", ISTM And unless you've fixed it already - the FAQ still refers to 7.1.3. Just to a grep of the source for '7.1.3' maybe. Chris