Re: [HACKERS] Beta time?
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?
>> 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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
... > 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
> > 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
> 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
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
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
> 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
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
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
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
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
> 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
"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
> 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
"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
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
"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
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
> 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
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
