Re: [HACKERS] A couple items on TODO
Tom Lane writes: Yeah, people have started to use 'const' in new code, but the older stuff doesn't use it, which means that the net effect is probably more annoyance than help. I'm afraid that if we attack this in an incremental way, we'll end up with code that may have a lot of const markers in the declarations, but the actual code is riddled with explicit casts to remove const because at one time or another that was necessary in a particular place. Can anyone think of a way to get from here to there without either a lot of leftover cruft, or a big bang massive changeover? What I usually do if I feel a parameter could be made const is to propagate the change as far as necessary to the underlying functions. From time to time this turns out to be impossible at some layer. BUT: This is an indicator that you really don't know whether the value is const so you shouldn't declare it thus. IMHO, a better project than putting const qualifiers all over interfaces that you are not familiar with would be to clean up all the -Wcast-qual warnings. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] A couple items on TODO
I also noticed that this item has been there for a while: *Encrpyt passwords in pg_shadow table using MD5 (Bruce, Vince) While you are there do you think it's possible to make an mcrypt function? :) See contrib/pgcrypto. -- 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] A couple items on TODO
As I was browsing TODO, I noticed a couple unassigned items that I may be able to help with (I haven't worked with the source before): *Add use of 'const' for variables in source tree I would discuss this item with the hackers list and see exactly what people want done with it. *Convert remaining fprintf(stderr,...)/perror() to elog() The issue here is that some calls can't use elog() because the context is not properly set up yet so we need to identify the non-elog error calls and figure out if they should be elog(). Neither seemed to be active at all. I also noticed that this item has been there for a while: *Encrpyt passwords in pg_shadow table using MD5 (Bruce, Vince) This is done. I forgot to mark it. I just marked it now. -- 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] A couple items on TODO
Peter Eisentraut [EMAIL PROTECTED] writes: Jeff Davis writes: *Convert remaining fprintf(stderr,...)/perror() to elog() This isn't quite as easy as a mechanical conversion, mind you, because elog of course has rather complex side effects besides printing out a message. AFAIR, elog at NOTICE or DEBUG level isn't really supposed to have any side-effects. The bigger issue is that you have to be careful about using it in certain places, mainly during startup or for reporting communication errors. (send failure - elog - tries to send message to client - send failure - elog - trouble) Also, I believe most of the printf's in the backend are in debugging support code that's not even compiled by default. The return on investment from converting those routines to use elog is really nil. There may be a few remaining printf calls that should be converted to elog, but I don't think this is a big issue. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] A couple items on TODO
AFAIR, elog at NOTICE or DEBUG level isn't really supposed to have any side-effects. The bigger issue is that you have to be careful about using it in certain places, mainly during startup or for reporting communication errors. (send failure - elog - tries to send message to client - send failure - elog - trouble) Also, I believe most of the printf's in the backend are in debugging support code that's not even compiled by default. The return on investment from converting those routines to use elog is really nil. There may be a few remaining printf calls that should be converted to elog, but I don't think this is a big issue. Clearly not a big issue, but something someone can poke around at to get started. -- 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] A couple items on TODO
Tom Lane writes: AFAIR, elog at NOTICE or DEBUG level isn't really supposed to have any side-effects. The bigger issue is that you have to be careful about using it in certain places, mainly during startup or for reporting communication errors. (send failure - elog - tries to send message to client - send failure - elog - trouble) It's especially postmaster.c and the related subroutines elsewhere that I'm not happy about. The postmaster would really need a way to report an error to the log and continue in its merry ways. This could probably be encapsulated in elog() by setting a flag variable I'm the postmaster -- might even exit already. Note: In my experience, the previous suggestion to return to the postmaster main loop on error would not really be useful. -- 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] A couple items on TODO
As I was browsing TODO, I noticed a couple unassigned items that I may be able to help with (I haven't worked with the source before): *Add use of 'const' for variables in source tree I would discuss this item with the hackers list and see exactly what people want done with it. I have noticed while working on command.c and heap.c that half the functions pass 'const char *' and the other half pass just 'char *'. This is a pain when you have a little helper function like 'is_relation(char *)' and you want to pass a 'const char *' to it and vice versa. ie. Compiler warnings - it's sort of annoying. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] A couple items on TODO
As I was browsing TODO, I noticed a couple unassigned items that I may be able to help with (I haven't worked with the source before): *Add use of 'const' for variables in source tree I would discuss this item with the hackers list and see exactly what people want done with it. I have noticed while working on command.c and heap.c that half the functions pass 'const char *' and the other half pass just 'char *'. This is a pain when you have a little helper function like 'is_relation(char *)' and you want to pass a 'const char *' to it and vice versa. ie. Compiler warnings - it's sort of annoying. Yes, it can be very annoying. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] A couple items on TODO
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I have noticed while working on command.c and heap.c that half the functions pass 'const char *' and the other half pass just 'char *'. This is a pain Yeah, people have started to use 'const' in new code, but the older stuff doesn't use it, which means that the net effect is probably more annoyance than help. I'm afraid that if we attack this in an incremental way, we'll end up with code that may have a lot of const markers in the declarations, but the actual code is riddled with explicit casts to remove const because at one time or another that was necessary in a particular place. Can anyone think of a way to get from here to there without either a lot of leftover cruft, or a big bang massive changeover? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] A couple items on TODO
*Add use of 'const' for variables in source tree I would discuss this item with the hackers list and see exactly what people want done with it. I have noticed while working on command.c and heap.c that half the functions pass 'const char *' and the other half pass just 'char *'. This is a pain when you have a little helper function like 'is_relation(char *)' and you want to pass a 'const char *' to it and vice versa. ie. Compiler warnings - it's sort of annoying. That's good information, now I have a better idea what I am looking for. I am using Source Navigator (good recommendation I got reading this list). I am basically just trying to find either variables that can be declared const, or inconsistancies (as Chris mentions). If anyone else has a clearer idea of what the intention of that todo item is, let me know. Jeff ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] A couple items on TODO
That's good information, now I have a better idea what I am looking for. I am using Source Navigator (good recommendation I got reading this list). I am basically just trying to find either variables that can be declared const, or inconsistancies (as Chris mentions). If anyone else has a clearer idea of what the intention of that todo item is, let me know. I assume that since most of the times char * is passed to a function, it is supposed to be unmodifiable. Putting the 'const' there enforces this - thereby making PostgreSQL more robust against poxy programming. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
