[BUGS] atan2 documentation bugs for 7.3 and 7.2
In the section on mathematical functions the following is given for atan2: atan2(x, y) inverse tangent of a/x I believe the correct version should either be: atan2(y, x) inverse tangent of y/x or atan2(x, y) inverse tangent of x/y I beleive the documentation was also wrong for 7.2 where it was: atan2(x, y) inverse tangent of y/x The postgres functions seems to be the same as glibc function of the same name when has the following man information: double atan2(double y, double x); DESCRIPTION The atan2() function calculates the arc tangent of the two variables x and y. It is similar to calculating the arc tangent of y / x, except that the signs of both arguments are used to determine the quadrant of the result. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bug #758: show_planner_stats does not work for new PREPARE calls
Barry Lind ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description show_planner_stats does not work for new PREPARE calls Long Description I was testing the 7.3 PREPARE functionality. I was using the timing information from show_parser_stats, show_planner_stats, show_executor_stats to compare times with and without using PREPARE. But unfortunatly no planing timing information is shown when using PREPARE so I can't see the total before and after information. Since all PREPARE is doing is parsing and planning the statement, it makes sense that it would show the planning information when show_planner_stats is enabled? Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Schemas not available for pl/pgsql %TYPE....
Sean Chittenden wrote: > Not a problem there. I walked around the code for a bit, made a few > hacks to see how things are working, and I can tell you strait up that > if you'd like this by 7.3, it won't be happening from me. <:~) I'm > stretched kinda thin as is and don't think I'll be able to get this > working correctly with time to test by release. I can send you the > patch I've got for the lexer, but that was chump. If you want to send me what you've done so far, I'll take a look and see if I can figure it out. I think this is probably a must do item for 7.3. Any further guidance or thoughts? Thanks, Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Schemas not available for pl/pgsql %TYPE....
> > ::sigh:: Is it me or does it look like all > > of pl/pgsql is schema un-aware (ie, all of the declarations). -sc > > Yeah. The group of routines parse_word, parse_dblword, etc that are > called by the lexer certainly all need work. There are some > definitional issues to think about, too --- plpgsql presently relies > on the number of names to give it some idea of what to look for, and > those rules are probably all toast now. Please come up with a > sketch of what you think the behavior should be before you start > hacking code. Not a problem there. I walked around the code for a bit, made a few hacks to see how things are working, and I can tell you strait up that if you'd like this by 7.3, it won't be happening from me. <:~) I'm stretched kinda thin as is and don't think I'll be able to get this working correctly with time to test by release. I can send you the patch I've got for the lexer, but that was chump. What I was going to do could be totally wrong, but... * Change the lexer to recognize schema.table.column%TYPE as a token and was going to create parse_tripwordtype() that'd look up the table and column in the appropriate schema and would return the appropriate type. If I were lazy, I'd just unshift the schema off of the token and return what comes back from parse_dblwordtype(), but that doesn't strike me as correct for something that's performance sensitive. Beyond doing that, I'm at a loss. :-/ Thoughts? -sc -- Sean Chittenden ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #756: suggestion: file with password instead of
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, next question. Is this something that can be fixed during beta. > > Yeah, I think so --- it's not forcing an initdb, so it won't be too > painful for beta testers. And once we release it will be very hard > to change the definition of the feature; better to get it right now. I am on it. -- 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 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: [BUGS] Bug #756: suggestion: file with password instead of
On 5 Sep 2002 at 12:33, Rod Taylor wrote: > My understanding is that it's a single password, not a list. > > As such you would probably not want a default, as each database you > connect to will (should?) have a different password. By setting a > default file we may encourage users to use the same password > throughout all PostgreSQL databases. If a password file could only hold a single password, one would constantly need to check and change the environmet variable when he frequently changes between different databases and that would IMHO withdraw most of the benefits of having such a file. I would rather want to have a single file, that can hold multiple entries and also allows commenting out entries. And why only put the passwords into that file? The entries could be complete connection info tuples including hostname, username, password, and maybe more parameters, so that databases can be addressed by a nickname. I think of something like --- snip --- foo password=foopass bar hostname=foo.bar.com dbname=foodb user=max password=xyz --- snap --- So even the remote "bar" database could be accessed by a simple $ psql bar If there is still need to have the password file on another than the default place, e.g. because the home directory is on NFS and thus considered unsafe, the file format could simply allow some sort of include command. cu Reinhard ---(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: [BUGS] Bug #756: suggestion: file with password instead of
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, next question. Is this something that can be fixed during beta. Yeah, I think so --- it's not forcing an initdb, so it won't be too painful for beta testers. And once we release it will be very hard to change the definition of the feature; better to get it right now. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #756: suggestion: file with password instead of
> > My understanding is that it's a single password, not a list. > > It isn't a single password. It is a file containing one password per > line with pattern matching. Oh, well in that case it should probably be a default spot in the home directory. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] pg-config --includedir-server
elein <[EMAIL PROTECTED]> writes: > Per docs 12.5.6 Writing Code I ran pg_config --includedir-server to verify > the location on the C include files. It said /usr/local/pgsql/include/server. > Neither the files nor the directory were there, however. Sounds like you did not do "make install-all-headers". regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #756: suggestion: file with password instead of
Rod Taylor wrote: > On Thu, 2002-09-05 at 12:14, Bruce Momjian wrote: > > Rod Taylor wrote: > > > On Thu, 2002-09-05 at 05:13, Reinhard Max wrote: > > > > On 4 Sep 2002 at 12:48, Rod Taylor wrote: > > > > > > > > > This item: > > > > > Add file to hold passwords using PGPASSWORDFILE environment variable > > > > > > > > > > Has been completed, and will be a part of the 7.3 release. > > > > > > > > Is there a default file name like ~/.pgpassword so that this feature > > > > can be used without setting yet another environment variable? > > > > > > I'm not entirely sure, but I don't believe so. You can read the 7.3 > > > docs at developer.postgresql.org. > > > > Is there a good reason for a default for this? If we have a default, > > there will be no way to disable the lookups except by renaming the file. > > On the other hand, no default means that people will make up their own > > names for the file, and that seems bad. > > My understanding is that it's a single password, not a list. It isn't a single password. It is a file containing one password per line with pattern matching. -- 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 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: [BUGS] Bug #756: suggestion: file with password instead of
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > >>> Is there a default file name like ~/.pgpassword so that this feature > >>> can be used without setting yet another environment variable? > > > Is there a good reason for a default for this? > > Well, most of the other packages I can think of have hard-wired > assumptions about names like "$HOME/.cvspass". If we have such a > default then there's little need for a PGPASSWORDFILE environment > variable at all. Perhaps we should go with the historical custom > and remove the env var in favor of a hardwired filename in $HOME. Yes, that is what I am thinking too. Do other packages allow you to override the default password file name? I don't think so. I don't see that in .ssh. OK, next question. Is this something that can be fixed during beta. I sure think so because if we don't we will have even more confusion for 7.4. -- 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: [BUGS] Bug #756: suggestion: file with password instead of
Bruce Momjian <[EMAIL PROTECTED]> writes: >>> Is there a default file name like ~/.pgpassword so that this feature >>> can be used without setting yet another environment variable? > Is there a good reason for a default for this? Well, most of the other packages I can think of have hard-wired assumptions about names like "$HOME/.cvspass". If we have such a default then there's little need for a PGPASSWORDFILE environment variable at all. Perhaps we should go with the historical custom and remove the env var in favor of a hardwired filename in $HOME. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #756: suggestion: file with password instead of
On Thu, 2002-09-05 at 12:14, Bruce Momjian wrote: > Rod Taylor wrote: > > On Thu, 2002-09-05 at 05:13, Reinhard Max wrote: > > > On 4 Sep 2002 at 12:48, Rod Taylor wrote: > > > > > > > This item: > > > > Add file to hold passwords using PGPASSWORDFILE environment variable > > > > > > > > Has been completed, and will be a part of the 7.3 release. > > > > > > Is there a default file name like ~/.pgpassword so that this feature > > > can be used without setting yet another environment variable? > > > > I'm not entirely sure, but I don't believe so. You can read the 7.3 > > docs at developer.postgresql.org. > > Is there a good reason for a default for this? If we have a default, > there will be no way to disable the lookups except by renaming the file. > On the other hand, no default means that people will make up their own > names for the file, and that seems bad. My understanding is that it's a single password, not a list. As such you would probably not want a default, as each database you connect to will (should?) have a different password. By setting a default file we may encourage users to use the same password throughout all PostgreSQL databases. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] pg-config --includedir-server
PostgreSQL 7.2.2 SuSe 7.3 This is a new installation not an update. (New machine ;-) If this is a bug it probably will only affect new/clean installations of 7.2.* Per docs 12.5.6 Writing Code I ran pg_config --includedir-server to verify the location on the C include files. It said /usr/local/pgsql/include/server. Neither the files nor the directory were there, however. pg_config --includedir showed one level up and it had some .h files and the internal and libpq include directories. postgres.h was not anywhere. Either the install forgot this piece or I needed to configure with some flag before I built. Configure only seems to know about --includedir not --includedir-server, though. I did not configure with --includedir as I believe it should be used to overwrite the default. (Correct me if that is not the case.) Either configure needs to have the includedir-server option added or revert to includedir, but the include files need to go somewhere besides the source tree. For new users this is sort of serious, however, new users probably won't go looking for the header files right away. I'm not following the bug mailing list, so please copy me on responses especially if I am way out in left field. elein [EMAIL PROTECTED] :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: [EMAIL PROTECTED] (510)543-6079 "Taking a Trip. Not taking a Trip." --anonymous :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #756: suggestion: file with password instead of
Rod Taylor wrote: > On Thu, 2002-09-05 at 05:13, Reinhard Max wrote: > > On 4 Sep 2002 at 12:48, Rod Taylor wrote: > > > > > This item: > > > Add file to hold passwords using PGPASSWORDFILE environment variable > > > > > > Has been completed, and will be a part of the 7.3 release. > > > > Is there a default file name like ~/.pgpassword so that this feature > > can be used without setting yet another environment variable? > > I'm not entirely sure, but I don't believe so. You can read the 7.3 > docs at developer.postgresql.org. Is there a good reason for a default for this? If we have a default, there will be no way to disable the lookups except by renaming the file. On the other hand, no default means that people will make up their own names for the file, and that seems bad. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #756: suggestion: file with password instead of
On Thu, 2002-09-05 at 05:13, Reinhard Max wrote: > On 4 Sep 2002 at 12:48, Rod Taylor wrote: > > > This item: > > Add file to hold passwords using PGPASSWORDFILE environment variable > > > > Has been completed, and will be a part of the 7.3 release. > > Is there a default file name like ~/.pgpassword so that this feature > can be used without setting yet another environment variable? I'm not entirely sure, but I don't believe so. You can read the 7.3 docs at developer.postgresql.org. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #756: suggestion: file with password instead of
On 4 Sep 2002 at 12:48, Rod Taylor wrote: > This item: > Add file to hold passwords using PGPASSWORDFILE environment variable > > Has been completed, and will be a part of the 7.3 release. Is there a default file name like ~/.pgpassword so that this feature can be used without setting yet another environment variable? cu Reinhard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
