Re: [HACKERS] Beta time?

2012-05-04 Thread Tom Lane
Josh Berkus  writes:
>> How are we handling the Monday release with everyone at PGCon?  Was that
>> resolved?

> I have yet to see a confirmed date, guys.  If we expect any support from
> the packagers and/or the advocacy volunteers, then people need at least
> a week's notice, probably more.

I haven't seen anybody positively say we can't do a wrap next Thursday
and release Monday, so I've been assuming that's what will happen.
If there are reasons to think it won't work, let's hear 'em now.

regards, tom lane

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


Re: [HACKERS] Beta time?

2012-05-04 Thread Josh Berkus

>> Next week, I thought.
> 
> How are we handling the Monday release with everyone at PGCon?  Was that
> resolved?

I have yet to see a confirmed date, guys.  If we expect any support from
the packagers and/or the advocacy volunteers, then people need at least
a week's notice, probably more.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

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


[HACKERS] Beta time?

2012-05-02 Thread Bruce Momjian
 On Wed, May 02, 2012 at 01:15:48PM -0400, Tom Lane wrote:
> Peter Eisentraut  writes:
> > On ons, 2012-05-02 at 00:31 -0400, Tom Lane wrote:
> >> Checking this patch, I noticed that config.guess and config.sub harbor
> >> most of the remaining references to those platforms, which reminded me:
> >> don't we usually update those files from autoconf upstream before beta?
> 
> > Yes, once we know when beta is, we can move on that. ;-)
> 
> Next week, I thought.

How are we handling the Monday release with everyone at PGCon?  Was that
resolved?

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

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


[HACKERS] Beta time approaching

2005-08-13 Thread Bruce Momjian
FYI, with the patch queue shrinking, it is time to consider a date for
beta. The current plan is to start beta in 7-10 days, so possible dates
are August 19 or 22.

We will need to have all major patches addressed, the release notes
done, and the major documentation usable.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[HACKERS] Beta time early next week

2004-11-10 Thread Bruce Momjian
FYI, I am going to need a few more days to apply patches submitted in
the past few days and Magnus needs a few more days to fix the windows
signal problems.  So, rather than planning a beta for later this week, I
think we should focus on early next week.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [HACKERS] beta time

2004-08-08 Thread Bruce Momjian
OK, I fixed the Win32 pgport build problem with Claudio's help.

I also fixed pg_dumpall on Win32 at the same time.

I might be out most of the day tomorrow.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] beta time

2004-08-07 Thread Joe Conway
Alvaro Herrera wrote:
Whitespace where?
OK, clarified:
 
  Syntax checking of array input processing has been tighened up
  considerably. Junk that was previously allowed in odd places with
  odd results now causes an ERROR. Also changed behavior with respect
  to whitespace surrounding array elements; trailing whitespace is now
  ignored as well as leading whitespace (which has always been ignored).
 
Thanks,
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [HACKERS] beta time

2004-08-07 Thread Alvaro Herrera
On Sat, Aug 07, 2004 at 10:09:22PM -0700, Joe Conway wrote:

>  
>   
>Syntax checking of array input processing has been tighened up
>considerably. Junk that was previously allowed in odd places with
>odd results now causes an ERROR. Also changed behavior with respect
>to whitespace; trailing whitespace is now ignored as well as leading
>whitespace (which has always been ignored).
>   
>  

Whitespace where?

-- 
Alvaro Herrera ()
"No hay ausente sin culpa ni presente sin disculpa" (Prov. francés)


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] beta time

2004-08-07 Thread Joe Conway
Tom Lane wrote:
Minor gripe: this bit of documentation seems out of date now.
!For example, elements containing curly braces, commas (or whatever the
!delimiter character is), double quotes, backslashes, or leading white
!space must be double-quoted.  To put a double quote or backslash in a
Should say "leading or trailing whitespace", no?
Good catch. Fixed.
Seems roughly the right amount of detail to me.  Note you should make
entries under both "observe the following incompatibilities" and the
general list of datatype/function changes.
Yup, figured that out after I sent the last post. Done.
Thanks,
Joe
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match


Re: [HACKERS] beta time

2004-08-07 Thread Tom Lane
Joe Conway <[EMAIL PROTECTED]> writes:
> I committed the attached.

Minor gripe: this bit of documentation seems out of date now.

!For example, elements containing curly braces, commas (or whatever the
!delimiter character is), double quotes, backslashes, or leading white
!space must be double-quoted.  To put a double quote or backslash in a

Should say "leading or trailing whitespace", no?

> Regarding the release notes, I take it that we should modify 
> doc/src/sgml/release.sgml?

Yup.

> Does the following sound reasonable, or 
> should I provide specific examples?

Seems roughly the right amount of detail to me.  Note you should make
entries under both "observe the following incompatibilities" and the
general list of datatype/function changes.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] beta time

2004-08-07 Thread Bruce Momjian
Joe Conway wrote:
> Tom Lane wrote:
> > Joe Conway <[EMAIL PROTECTED]> writes:
> >>1. '{{"1 2" x},{3}}'
> >>2. '{{},{}}'
> > 
> >>My patch would generate an ERROR for either. Tom, you questioned my 
> >>disallowing of both of these, but didn't seem to have a very strong 
> >>opinion.
> > 
> > I don't have any great love for the first item --- I think it was an
> > unintended consequence of the way the code was first written, rather
> > than something the author meant to support.
> > 
> > I'm more concerned about what the second should mean, but I do have to
> > concede that we'd likely want to appropriate this syntax to mean NULL
> > array entries as soon as we support NULL array entries.  So rejecting it
> > at the moment may be a forward-looking thing to do.
> 
> I committed the attached.
> 
> Regarding the release notes, I take it that we should modify 
> doc/src/sgml/release.sgml? Does the following sound reasonable, or 

Right.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] beta time

2004-08-07 Thread Joe Conway
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
1. '{{"1 2" x},{3}}'
2. '{{},{}}'

My patch would generate an ERROR for either. Tom, you questioned my 
disallowing of both of these, but didn't seem to have a very strong 
opinion.
I don't have any great love for the first item --- I think it was an
unintended consequence of the way the code was first written, rather
than something the author meant to support.
I'm more concerned about what the second should mean, but I do have to
concede that we'd likely want to appropriate this syntax to mean NULL
array entries as soon as we support NULL array entries.  So rejecting it
at the moment may be a forward-looking thing to do.
I committed the attached.
Regarding the release notes, I take it that we should modify 
doc/src/sgml/release.sgml? Does the following sound reasonable, or 
should I provide specific examples?

 
  
   Syntax checking of array input processing has been tighened up
   considerably. Junk that was previously allowed in odd places with
   odd results now causes an ERROR. Also changed behavior with respect
   to whitespace; trailing whitespace is now ignored as well as leading
   whitespace (which has always been ignored).
  
 
Joe
Index: doc/src/sgml/array.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/array.sgml,v
retrieving revision 1.36
diff -c -r1.36 array.sgml
*** doc/src/sgml/array.sgml	5 Aug 2004 03:29:11 -	1.36
--- doc/src/sgml/array.sgml	8 Aug 2004 04:49:48 -
***
*** 95,104 
  
 where delim is the delimiter character
 for the type, as recorded in its pg_type entry.
!(For all built-in types, this is the comma character
!,.)  Each
!val is either a constant of the array
!element type, or a subarray.  An example of an array constant is
  
  '{{1,2,3},{4,5,6},{7,8,9}}'
  
--- 95,106 
  
 where delim is the delimiter character
 for the type, as recorded in its pg_type entry.
!Among the standard data types provided in the
!PostgreSQL distribution, type
!box uses a semicolon (;) but all the others
!use comma (,). Each val is
!either a constant of the array element type, or a subarray. An example
!of an array constant is
  
  '{{1,2,3},{4,5,6},{7,8,9}}'
  
***
*** 161,167 
   
  
   
!   The ARRAY expression syntax may also be used:
  
  INSERT INTO sal_emp
  VALUES ('Bill',
--- 163,169 
   
  
   
!   The ARRAY constructor syntax may also be used:
  
  INSERT INTO sal_emp
  VALUES ('Bill',
***
*** 176,183 
Notice that the array elements are ordinary SQL constants or
expressions; for instance, string literals are single quoted, instead of
double quoted as they would be in an array literal.  The ARRAY
!   expression syntax is discussed in more detail in .
   
   
  
--- 178,185 
Notice that the array elements are ordinary SQL constants or
expressions; for instance, string literals are single quoted, instead of
double quoted as they would be in an array literal.  The ARRAY
!   constructor syntax is discussed in more detail in
!   .
   
   
  
***
*** 524,533 
 use comma.)  In a multidimensional array, each dimension (row, plane,
 cube, etc.) gets its own level of curly braces, and delimiters
 must be written between adjacent curly-braced entities of the same level.
!You may write whitespace before a left brace, after a right
!brace, or before any individual item string.  Whitespace after an item
!is not ignored, however: after skipping leading whitespace, everything
!up to the next right brace or delimiter is taken as the item value.

  

--- 526,542 
 use comma.)  In a multidimensional array, each dimension (row, plane,
 cube, etc.) gets its own level of curly braces, and delimiters
 must be written between adjacent curly-braced entities of the same level.
!   
! 
!   
!The array output routine will put double quotes around element values
!if they are empty strings or contain curly braces, delimiter characters,
!double quotes, backslashes, or white space.  Double quotes and backslashes
!embedded in element values will be backslash-escaped.  For numeric
!data types it is safe to assume that double quotes will never appear, but
!for textual data types one should be prepared to cope with either presence
!or absence of quotes.  (This is a change in behavior from pre-7.2
!PostgreSQL releases.)

  

***
*** 573,598 
  

 As shown previously, when writing an array value you may write double
!quotes around any individual array
!element.  You must do so if the element value would otherwise
!confuse the array-value parser.  For example, elements containing curly
!braces, commas (or whatever the delimiter character is), double quotes,
!backslashes, or leading white space must be 

Re: [HACKERS] beta time

2004-08-07 Thread Marc G. Fournier
On Sat, 7 Aug 2004, Tom Lane wrote:
The plan was to wrap beta1 sometime tomorrow ... I'd guess that 
"sometime" will end up being in the afternoon east coast time, but this 
largely depends on the libpgport breakage ...
That's what I was figuring (re: libpgport) ... hopefully I'm following the 
right one, but am following the thread, and will hold off pending 
resolution ...


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [HACKERS] beta time

2004-08-07 Thread Tom Lane
Joe Conway <[EMAIL PROTECTED]> writes:
> I was waiting on feedback on two issues before committing:

> 1. '{{"1 2" x},{3}}'
> 2. '{{},{}}'

> My patch would generate an ERROR for either. Tom, you questioned my 
> disallowing of both of these, but didn't seem to have a very strong 
> opinion.

I don't have any great love for the first item --- I think it was an
unintended consequence of the way the code was first written, rather
than something the author meant to support.

I'm more concerned about what the second should mean, but I do have to
concede that we'd likely want to appropriate this syntax to mean NULL
array entries as soon as we support NULL array entries.  So rejecting it
at the moment may be a forward-looking thing to do.

> BTW, when is the planned cutoff for commits to get into the beta?

The plan was to wrap beta1 sometime tomorrow ... I'd guess that
"sometime" will end up being in the afternoon east coast time, but
this largely depends on the libpgport breakage ...

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] beta time

2004-08-07 Thread Bruce Momjian
Joe Conway wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>Tom, when you updated the release notes, did you do a CVS log and
> >>already get all the new stuff as of Aug 6?
> > 
> > Yes I did.  I think the release notes are good to go for beta,
> > with the possible exception of mentioning any array-input-parsing
> > hacking that Joe might be about to commit.
> 
> I was waiting on feedback on two issues before committing:
> 
> 1. '{{"1 2" x},{3}}'
> 2. '{{},{}}'
> 
> My patch would generate an ERROR for either. Tom, you questioned my 
> disallowing of both of these, but didn't seem to have a very strong 
> opinion. No one else has chimed in at all (including no replies to my 
> post on GENERAL earlier). Can I go with what I have, at the risk of 
> ripping it out if others complain?
> 
> If so, I'll commit what I posted last night, and amend the docs. I will 
> also update the release notes.

OK, it has to go in the incompatibilities section, right?

> BTW, when is the planned cutoff for commits to get into the beta?

When everyone is done sometime tomorrow.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] beta time

2004-08-07 Thread Joe Conway
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom, when you updated the release notes, did you do a CVS log and
already get all the new stuff as of Aug 6?
Yes I did.  I think the release notes are good to go for beta,
with the possible exception of mentioning any array-input-parsing
hacking that Joe might be about to commit.
I was waiting on feedback on two issues before committing:
1. '{{"1 2" x},{3}}'
2. '{{},{}}'
My patch would generate an ERROR for either. Tom, you questioned my 
disallowing of both of these, but didn't seem to have a very strong 
opinion. No one else has chimed in at all (including no replies to my 
post on GENERAL earlier). Can I go with what I have, at the risk of 
ripping it out if others complain?

If so, I'll commit what I posted last night, and amend the docs. I will 
also update the release notes.

BTW, when is the planned cutoff for commits to get into the beta?
Thanks,
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


Re: [HACKERS] beta time

2004-08-07 Thread Bruce Momjian
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I have two things left before beta. I want to make sure the release
> >> notes are current against CVS and I want to make sure the win32
> >> tablespace symlink changes I just made work.
> 
> > Tom, when you updated the release notes, did you do a CVS log and
> > already get all the new stuff as of Aug 6?
> 
> Yes I did.  I think the release notes are good to go for beta,
> with the possible exception of mentioning any array-input-parsing
> hacking that Joe might be about to commit.

OK.  Thanks for doing that.

> I think though that we might have some other must-fix Win32 issues :-(.
> What are we going to do about this libpgport-depends-on-the-backend
> business?

I have Claudio on IM right now and am getting the details.  I wasn't
aware it was such a problem but I think it was introduced by rmtree()
and the malloc call.  

What I would like to do is to move elog/fprintf out of /port and make a
generic pglog call and have a backend function that calls elog and a
libpq version that calls fprintf.  This would remove a lot of FRONTEND
and Makefile compiles and will probably avoid some bugs.  The only
tricky part is passing a variable number of arguments. Same behavior for
malloc/palloc.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [HACKERS] beta time

2004-08-07 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I have two things left before beta. I want to make sure the release
>> notes are current against CVS and I want to make sure the win32
>> tablespace symlink changes I just made work.

> Tom, when you updated the release notes, did you do a CVS log and
> already get all the new stuff as of Aug 6?

Yes I did.  I think the release notes are good to go for beta,
with the possible exception of mentioning any array-input-parsing
hacking that Joe might be about to commit.

I think though that we might have some other must-fix Win32 issues :-(.
What are we going to do about this libpgport-depends-on-the-backend
business?

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] beta time

2004-08-07 Thread Bruce Momjian
Bruce Momjian wrote:
> I have two things left before beta. I want to make sure the release
> notes are current against CVS and I want to make sure the win32
> tablespace symlink changes I just made work.
> 

Tom, when you updated the release notes, did you do a CVS log and
already get all the new stuff as of Aug 6?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


[HACKERS] beta time

2004-08-07 Thread Bruce Momjian
I have two things left before beta. I want to make sure the release
notes are current against CVS and I want to make sure the win32
tablespace symlink changes I just made work.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [HACKERS] Beta time

2001-10-04 Thread Thomas Lockhart

...
> OK, can I get another vote for that date.

What was wrong with the 10th? I'm going to be tied up for most of the
time between now and Monday.

 - Thomas

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Beta time

2001-10-04 Thread Bruce Momjian

> > On Thu, 4 Oct 2001, Bruce Momjian wrote:
> >> Can we set a date for beta?  If we are at least a week away, we should
> >> say that so people know they can keep working.
> 
> I do not think we should slip it yet again, and especially not tell
> people "hey, send in more features", because that will lead to further
> slip.
> 
> How about this Monday (10/8)?

OK, can I get another vote for that date.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] Beta time

2001-10-04 Thread Tom Lane

> On Thu, 4 Oct 2001, Bruce Momjian wrote:
>> Can we set a date for beta?  If we are at least a week away, we should
>> say that so people know they can keep working.

I do not think we should slip it yet again, and especially not tell
people "hey, send in more features", because that will lead to further
slip.

How about this Monday (10/8)?

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Beta time

2001-10-04 Thread Vince Vielhaber

On Thu, 4 Oct 2001, Bruce Momjian wrote:

> Can we set a date for beta?  If we are at least a week away, we should
> say that so people know they can keep working.

If we say the 10th I won't have to change the developer's page :)

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directoryhttp://www.camping-usa.com
   Online Giftshop Superstorehttp://www.cloudninegifts.com
==




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] Beta time

2001-10-04 Thread Bruce Momjian

Can we set a date for beta?  If we are at least a week away, we should
say that so people know they can keep working.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Beta time

2001-09-25 Thread Bruce Momjian

> Marc G. Fournier writes:
> 
> > with all the changes going on, we're most likely looking at Oct 1st,
> > earliest ... things are startin to stabilize, but until that 18gig is
> > installed next week, we still have th eproblems with updating ftp, unless
> > Peter can clear out th e400+Meg in his acount? :)
> 
> Uh, I only saw 180 MB.  I reduced it to 113 now.

I got rid of my CVS copy, freeing 33MB.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Beta time

2001-09-24 Thread Peter Eisentraut

Marc G. Fournier writes:

> with all the changes going on, we're most likely looking at Oct 1st,
> earliest ... things are startin to stabilize, but until that 18gig is
> installed next week, we still have th eproblems with updating ftp, unless
> Peter can clear out th e400+Meg in his acount? :)

Uh, I only saw 180 MB.  I reduced it to 113 now.

-- 
Peter Eisentraut   [EMAIL PROTECTED]   http://funkturm.homeip.net/~peter



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



Re: [HACKERS] Beta time

2001-09-23 Thread Marc G. Fournier


with all the changes going on, we're most likely looking at Oct 1st,
earliest ... things are startin to stabilize, but until that 18gig is
installed next week, we still have th eproblems with updating ftp, unless
Peter can clear out th e400+Meg in his acount? :)

On Sun, 23 Sep 2001, Bruce Momjian wrote:

> I know we had expected beta last Friday, but I think the needed CVS
> changes have delayed that.  I know a few people are working on final
> additions.  Perhaps this Friday would be a good beta target.
>
> Tom and I will be at the OSDN conference until Wednesday.
>
> --
>   Bruce Momjian|  http://candle.pha.pa.us
>   [EMAIL PROTECTED]   |  (610) 853-3000
>   +  If your life is a hard drive, |  830 Blythe Avenue
>   +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026
>
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
>


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[HACKERS] Beta time

2001-09-23 Thread Bruce Momjian

I know we had expected beta last Friday, but I think the needed CVS
changes have delayed that.  I know a few people are working on final
additions.  Perhaps this Friday would be a good beta target.

Tom and I will be at the OSDN conference until Wednesday.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] Beta time

2001-09-22 Thread Tom Lane

Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I'd suggest issuing the NOTICE inside the loop, actually,
>> and not breaking at all.  (See also #4)

> I don't quite understand what you mean here?

Just do elog(NOTICE) inside the loop over indexes, rather than setting a
flag to do it later.  For that matter, I see no reason not to raise the
elog(ERROR) condition inside the loop, rather than setting a flag to
do it later.

> I admit I was confused as to why it's keyno - 1??

To make a zero-based C array index from the one-based attribute number.
But the problem with this code is it doesn't handle indexes on system
attributes such as OID, which have negative attribute numbers and are
not shown in rel->rd_att->attrs.  I'd be inclined to use get_attname,
and not bother with looking into the relcache rd_att structure at all.

> I was going to do this, but then realised all I had access to in the
> indexStruct was the oid of the index relation?  What's the easiest way of
> retrieving the name of an index given it's oid, or the oid of it's
> relation?

get_rel_name

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Beta time

2001-09-22 Thread Christopher Kings-Lynne

> 1. Should not "break" out of loop over indexes after detecting a
> matching non-primary-key index.  This allows detection of the NOTICE
> condition to distract you from detecting the ERROR condition on a
> later index.  I'd suggest issuing the NOTICE inside the loop, actually,
> and not breaking at all.  (See also #4)

I don't quite understand what you mean here?

> 2. What's with the "if (keyno > 0)"?  That breaks detection of
> everything on indexes on system columns, eg OID.  (Of course, the
> "rel_attrs[keyno - 1]" reference doesn't work for system columns,
> but sticking your head in the sand is no answer.)

That is that part of the code that I least understand, so I would
appreciate it if someone took 1 minute and told me how this _should_ be
written.  Note that I used this code from the ADD FOREIGN KEY stuff.

 /* Look at key[i] in the index and check that it is over the same column
as key[i] in the constraint.  This is to differentiate between (a,b)
and (b,a) */
 if (i < INDEX_MAX_KEYS && indexStruct->indkey[i] != 0)
 {
intkeyno = indexStruct->indkey[i];

if (keyno > 0)
{
   char  *name = NameStr(rel_attrs[keyno - 1]->attname);
   if (strcmp(name, key->name) == 0) keys_matched++;
}
 }

I admit I was confused as to why it's keyno - 1??

> 3. pfree'ing iname at the bottom doesn't strike me as a good
> idea; isn't that possibly part of your input querytree?

OK, gone.

> 4. If you're going to be so pedantic as to issue a warning notice about
> a duplicate non-primary index, it'd be polite to give the name of that
> index.  Else how shall I know which index you think I should drop?

I was going to do this, but then realised all I had access to in the
indexStruct was the oid of the index relation?  What's the easiest way of
retrieving the name of an index given it's oid, or the oid of it's
relation?

Once I've figured these probs out, I'll fix the ADD UNIQUE code as well.

Chris



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



Re: [HACKERS] Beta time

2001-09-19 Thread Tom Lane

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> 3. pfree'ing iname at the bottom doesn't strike me as a good
>> idea; isn't that possibly part of your input querytree?

> Hmmm.  OK.  What about in the case where iname is null and I give it a
> makeObjectName?

Don't worry about it.  palloc'd space will be recovered anyway at end of
statement.  It's really not worth the code space to pfree every little
bit of space you might use, except in routines that could be executed
many times in a single query.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] Beta time

2001-09-18 Thread Christopher Kings-Lynne

> 1. Should not "break" out of loop over indexes after detecting a
> matching non-primary-key index.  This allows detection of the NOTICE
> condition to distract you from detecting the ERROR condition on a
> later index.  I'd suggest issuing the NOTICE inside the loop, actually,
> and not breaking at all.  (See also #4)

OK.

> 2. What's with the "if (keyno > 0)"?  That breaks detection of
> everything on indexes on system columns, eg OID.  (Of course, the
> "rel_attrs[keyno - 1]" reference doesn't work for system columns,
> but sticking your head in the sand is no answer.)

This is code that I've borrowed from elsewhere.  I'll have a good look at it
tho.

> 3. pfree'ing iname at the bottom doesn't strike me as a good
> idea; isn't that possibly part of your input querytree?

Hmmm.  OK.  What about in the case where iname is null and I give it a
makeObjectName?

> 4. If you're going to be so pedantic as to issue a warning notice about
> a duplicate non-primary index, it'd be polite to give the name of that
> index.  Else how shall I know which index you think I should drop?

I'll improve the messages.  As for me being pedantic - that's a result of
what you specified as the best behaviour should be when I posted on the
list!

You may also want to look at the CONSTR_UNIQUE block that's already been
committed, as it may also have similar issues.  Any fixes I make to PRIMARY,
I will also fix in UNIQUE...

Cheers,

Chris


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] Beta time

2001-09-18 Thread Tom Lane

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Attached is the CONSTR_PRIMARY switch block from command.c.  I've marked the
> problem test with '@@'.

Hmmm  this code has got a number of problems, but I don't see why
*that* would fail.  Anyone?

What I do see:

1. Should not "break" out of loop over indexes after detecting a
matching non-primary-key index.  This allows detection of the NOTICE
condition to distract you from detecting the ERROR condition on a
later index.  I'd suggest issuing the NOTICE inside the loop, actually,
and not breaking at all.  (See also #4)

2. What's with the "if (keyno > 0)"?  That breaks detection of
everything on indexes on system columns, eg OID.  (Of course, the
"rel_attrs[keyno - 1]" reference doesn't work for system columns,
but sticking your head in the sand is no answer.)

3. pfree'ing iname at the bottom doesn't strike me as a good
idea; isn't that possibly part of your input querytree?

4. If you're going to be so pedantic as to issue a warning notice about
a duplicate non-primary index, it'd be polite to give the name of that
index.  Else how shall I know which index you think I should drop?

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])



Re: [HACKERS] Beta time

2001-09-18 Thread Christopher Kings-Lynne

Attached is the CONSTR_PRIMARY switch block from command.c.  I've marked the
problem test with '@@'.

Basically the patch all seems to work properly, except that it doesn't
recognise existing primarty keys.  ie. You can go ALTER TABLE test ADD
PRIMARY KEY(a) multiple times and it will keep adding a primary key.  My ADD
UNIQUE patch that has been committed is virtually identical, and has no such
problem.

Chris

> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 18 September 2001 12:41 PM
> To: Christopher Kings-Lynne
> Cc: Bruce Momjian; PostgreSQL-development
> Subject: Re: [HACKERS] Beta time
>
>
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > I am checking the indexStruct->indisprimary field, but it
> always resolves to
> > false.  indisunique works fine.  It is a trivial change to the
> ADD UNIQUE
> > code, but it doesn't work.  Viewing the system catalogs and
> '\d' both show
> > the indices as primary, but the SearchSysCache funtion believes
> that they
> > are not.
>
> Doesn't make any sense to me either.  Want to post your code?
>
>   regards, tom lane
>

 command.c


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Beta time

2001-09-17 Thread Tom Lane

"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I am checking the indexStruct->indisprimary field, but it always resolves to
> false.  indisunique works fine.  It is a trivial change to the ADD UNIQUE
> code, but it doesn't work.  Viewing the system catalogs and '\d' both show
> the indices as primary, but the SearchSysCache funtion believes that they
> are not.

Doesn't make any sense to me either.  Want to post your code?

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Beta time

2001-09-17 Thread Christopher Kings-Lynne

I spent an hour or two trying to get my ADD PRIMARY KEY patch to work but
I'm beginning to think my code is suffering from bit rot.  Basically, during
the iteration over the indices on the table, looking for other primary
indices, none are found.

I am checking the indexStruct->indisprimary field, but it always resolves to
false.  indisunique works fine.  It is a trivial change to the ADD UNIQUE
code, but it doesn't work.  Viewing the system catalogs and '\d' both show
the indices as primary, but the SearchSysCache funtion believes that they
are not.

Is DefineIndex for primary indices broken or something?

I have tried putting a CommandCounterIncrement() in there out of
desperation, but it does nothing.  Does anyone have any ideas?  Might have
to leave it for 7.3 I guess.

Chris

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> Sent: Tuesday, 18 September 2001 12:00 AM
> To: PostgreSQL-development
> Subject: [HACKERS] Beta time
>
>
> I want to mention that the number of patches submitted has dropped off
> dramatically.  Seems people are prepared for beta and we should start
> beta as soon as we can.  I think the current plan is Friday.
>
> Also, I will be on vacation this week.  Tom will apply any patches that
> look good.
>
> --
>   Bruce Momjian|  http://candle.pha.pa.us
>   [EMAIL PROTECTED]   |  (610) 853-3000
>   +  If your life is a hard drive, |  830 Blythe Avenue
>   +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] Beta time

2001-09-17 Thread Thomas Lockhart

> I want to mention that the number of patches submitted has dropped off
> dramatically.  Seems people are prepared for beta and we should start
> beta as soon as we can.  I think the current plan is Friday.

I'm doing a substantial amount of work on the date/time types. Not
certain it will be ready for Friday. Will know more by then, of course
;)

- Thomas

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] Beta time

2001-09-17 Thread Bruce Momjian

I want to mention that the number of patches submitted has dropped off
dramatically.  Seems people are prepared for beta and we should start
beta as soon as we can.  I think the current plan is Friday.

Also, I will be on vacation this week.  Tom will apply any patches that
look good.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 853-3000
  +  If your life is a hard drive, |  830 Blythe Avenue
  +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html