Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
I have to say that during beta testing I ALWAYS do an initdb and a reload just to make sure the pg_dumpall and pg_restore stuff works right. Plus to make sure problems that might only pop up with a new initdb are found as well. I probably burn it to the ground several times on a single beta just to test different data sets and I prefer a clean database when doing that so I'm sure the problems I see are from just that one dataset. So, Requiring an initdb for every beta wouldn't bother me one bit. To me you test a beta by migrating to it just like it was a production version, and that means a new build from the ground up, initdb and all. On 18 Sep 2002, Neil Conway wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 18 Sep 2002, Bruce Momjian wrote: We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. Right, and? How many times in the past has it been the last beta in the cycle that forced the initdb? Are you able to guarantee that there won't* be another initdb required if we wait until mid-next week? I completely agree with Bruce here. Requiring an initdb for every beta release significantly reduces the number of people who will be willing to try it out -- so initdb's between betas are not disasterous, but should be avoided if possible. Since waiting till next week significantly reduces the chance of an initdb for beta3 and has no serious disadvantage that I can see, it seems the right decision to me. Cheers, Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Thu, 19 Sep 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Thu, 19 Sep 2002, Bruce Momjian wrote: It is an open issue. It has to be resolved. When it is, I will remove it. I added a question mark to it but it needs to be tracked. I keep having to add and remove it because I have people telling me what to do. It was Peter who told me to add it, and you and Thomas to remove it. It isn't me adding/removing on my own. Right, so you have two telling you to remove it, one telling you to add it, and two that are discussion why/if it *should* be added ... Tom feels it should be added, and I'm clarifing the why of it ... don't re-add it until we've determined *if* it is actually an open issue or not ... stop jumping the gun ... I will make the decision. If you want to maintain your own open items list, go ahead. Ah, okay, so your list doesn't necessarily follow reality, its more for your own use ... k, as long as we have that clarified, we're fine ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Bruce Momjian [EMAIL PROTECTED] writes: Looking at the open item list, I see: fix up function return types on lang/type/trigger creation or loosen opaque restrictions Seems that should be fixed before beta2 because it does effect people loading data. Yeah, we should do something with that. Are people okay with the idea of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE to the correct thing? Are we done with all of these? Add casts: (Tom) assignment-level cast specification inet - text macaddr - text int4 - varchar? int8 - varchar? add param for length check for char()/varchar() All but the inet/macaddr-text change; I backed that out after finding that it induced a bunch of regression-test failures. The tests assume that inet = integer will provoke a failure. Guess what: if both inet and integer have implicit casts to text, the system takes it. On reflection I still feel that we should be getting rid of implicit casts to text rather than adding more. This is still an open bug: http://archives.postgresql.org/pgsql-bugs/2001-10/msg00108.php regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: Who implemented SIMILAR TO in the first place? Thomas. He put in the syntax, but as it stands it's simply syntactic sugar for ~ --- that is, our Posix-compatible regex match operator. Since the spec demands very non-Posix behavior, this is wrong. AFAICS, getting SIMILAR TO to operate per spec would require adding some sort of translation function that converts the spec-style pattern into a Posix pattern that our regex match engine would handle. This would at least require adding ^ and $ around the pattern, converting the escape character if any, and translating % and _ into .* and . respectively. There are probably some differences of detail that we'd need to fix later, but that would get it to a state where we need not be ashamed to release it. We already have a similar mechanism for handling LIKE ... ESCAPE clauses, so it doesn't seem too difficult to do. But I haven't got time for it... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: Right, so you have two telling you to remove it, one telling you to add it, and two that are discussion why/if it *should* be added ... Tom feels it should be added, and I'm clarifing the why of it ... don't re-add it until we've determined *if* it is actually an open issue or not ... stop jumping the gun ... It *is* an open issue, Marc: Peter and I think so, at least. You cannot declare by fiat that it isn't. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Tom Lane wrote: AFAICS, getting SIMILAR TO to operate per spec would require adding some sort of translation function that converts the spec-style pattern into a Posix pattern that our regex match engine would handle. This would at least require adding ^ and $ around the pattern, converting the escape character if any, and translating % and _ into .* and . respectively. There are probably some differences of detail that we'd need to fix later, but that would get it to a state where we need not be ashamed to release it. We already have a similar mechanism for handling LIKE ... ESCAPE clauses, so it doesn't seem too difficult to do. But I haven't got time for it... It seems like a merge of regex and LIKE patterns. ANSI doesn't have regex so maybe SIMILAR TO is their solution to that. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Tom Lane writes: Yeah, we should do something with that. Are people okay with the idea of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE to the correct thing? Seems like an appropriate time to throw a notice, though. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Can I buy an extra day or two? I'm in DC till Saturday then there's the trip home. How 'bout a wednesday beta release? On Thu, 19 Sep 2002, Marc G. Fournier wrote: On Wed, 18 Sep 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... I want to review and apply Alvaro's attisinherited fix before we go beta2. I think I can get that done tomorrow. I can't recall any other initdb-forcing fixes in the pipeline; Bruce, do you? Which is not to say we don't have a ton of known bugs to fix... I'd lean towards a Monday-ish beta2 myself. 'k, then let's go with a Sunday night packaging, Monday announce, so that we have beta2 testing starting right at the beginning of the week ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.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
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Yeah, we should do something with that. Are people okay with the idea of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE to the correct thing? Seems like an appropriate time to throw a notice, though. Of course. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Yeah, we should do something with that. Are people okay with the idea of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE to the correct thing? Seems like an appropriate time to throw a notice, though. Of course. Now that we have additional elog levels, is it a NOTICE or a WARNING. I am leaning to the latter. -- 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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Yeah, we should do something with that. Are people okay with the idea of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE to the correct thing? Seems like an appropriate time to throw a notice, though. Of course. Now that we have additional elog levels, is it a NOTICE or a WARNING. I am leaning to the latter. NOTICE seems sufficient to me. 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] Open 7.3 items
There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? For those interested in PostgreSQL + FreeBSD, I have a patch pending approval that will let developers toggle between a devel port and the stable release for all ports that depend on PostgreSQL. -sc -- Sean Chittenden ---(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] Open 7.3 items
Bruce Momjian writes: There has been a lot of activity on open items in the past week. Here is the updated list. SIMILAR TO and the associated SUBSTRING functionality need to be fixed. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
Gavin Sherry wrote: Change log_min_error_statement to be off by default (Gavin) I will be happy to provide this simple fix once I can get some indication of the preferred implication. The discussion left off with Bruce prefering that the GUC code for the *_min_* variables be variable specific where as Tom saw no need to back out the generic assignment function I provided, despite the fact that it behaves `illogically' (client_min_messages = FATAL?). Thanks, Gavin. Tom convinced me that it was OK to have illogical values. Also, I think we need to support PANIC for server_min_messages anyway to use as a default value for 'off'. Does that make sense? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Sean Chittenden wrote: There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? For those interested in PostgreSQL + FreeBSD, I have a patch pending approval that will let developers toggle between a devel port and the stable release for all ports that depend on PostgreSQL. I have heard end of this week or next week for beta2. Also, plan was to split the CVS tree at that time. -- 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] Open 7.3 items
Thomas Lockhart wrote: ... Fix SIMILAR TO to be Posix compiant or remove it Sorry, was there a decision here? No one has described the problem, just declared that there is one and declared that the feature should be removed. In the old days, one might have expected to approach this differently, with a contribution to help fix a problem, after describing it. I'm not quite understanding the current process, if there is one. I had it in my mailbox as an unresolved issue. Peter wanted it added so I did it. I don't know the issue either. If you want it removed from open item, I will do that too. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
On Wed, 18 Sep 2002, Bruce Momjian wrote: On Going Point-in-time recovery Win32 port these have nothing to do with v7.3, so shouldn't even be listed here ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: On Going Point-in-time recovery Win32 port these have nothing to do with v7.3, so shouldn't even be listed here ... OK, removed. -- 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
Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Sean Chittenden wrote: There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? I was actually going to post this tonight anyway ... its been 2 weeks, and since nobody should be committing anything but fixes (right guys?), I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... Bruce, can you make sure that any changes needed prior to my packaging are done before noon ADT on Friday? I have no doubt that we have some outstanding issues to work through, but this will give a new checkpoint for those testing ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Sean Chittenden wrote: There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? I was actually going to post this tonight anyway ... its been 2 weeks, and since nobody should be committing anything but fixes (right guys?), I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... Bruce, can you make sure that any changes needed prior to my packaging are done before noon ADT on Friday? I have no doubt that we have some outstanding issues to work through, but this will give a new checkpoint for those testing ... We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. -- 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])
The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: Thomas Lockhart wrote: ... Fix SIMILAR TO to be Posix compiant or remove it Sorry, was there a decision here? No one has described the problem, just declared that there is one and declared that the feature should be removed. In the old days, one might have expected to approach this differently, with a contribution to help fix a problem, after describing it. I'm not quite understanding the current process, if there is one. I had it in my mailbox as an unresolved issue. Peter wanted it added so I did it. I don't know the issue either. If you want it removed from open item, I will do that too. Well, if nobody can identify what exactly the problem is, it should definitely be removed from the Open Items list ... maybe we need to lay down some 'rules' for the TODO list? Some sort of criteria other hten someone suggested it to work with? For instance, change the TODO to a pseudo-FAQ format ... where an item added to it has to have some sort of 'associated' description? For instance, how is SIMILAR TO *not* Posix compliant? What *is* a Posix compliant version? Where is such compliance defined? Is there a reference? Also, since when has 'lack of compliance' been basis to remove something ... its not fully compliant, so even partial functionality isn't allowed? Basically, there should be *some* basis for an item to be on the TODO list ... some sort this is how it should be ... How many items on the TODO list are ones that nobody even knows what they are about anymore? :) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: Well, if nobody can identify what exactly the problem is, it should definitely be removed from the Open Items list ... maybe we need to lay down some 'rules' for the TODO list? Some sort of criteria other hten someone suggested it to work with? For instance, change the TODO to a pseudo-FAQ format ... where an item added to it has to have some sort of 'associated' description? For instance, how is SIMILAR TO *not* Posix compliant? What *is* a Posix compliant version? Where is such compliance defined? Is there a reference? Also, since when has 'lack of compliance' been basis to remove something ... its not fully compliant, so even partial functionality isn't allowed? Basically, there should be *some* basis for an item to be on the TODO list ... some sort this is how it should be ... How many items on the TODO list are ones that nobody even knows what they are about anymore? :) I think you are confusing the open items list with the TODO list. TODO usually has some basis, while open items is just that, things we need to decide on. Peter brought it up and wanted it on the list so I put it on. I can be taken off just as easily. I put Peter's name on the item, and a question mark. The open items list is just so we don't forget things. -- 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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. Right, and? How many times in the past has it been the last beta in the cycle that forced the initdb? Are you able to guarantee that there *won't* be another initdb required if we wait until mid-next week? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: I think you are confusing the open items list with the TODO list. TODO usually has some basis, while open items is just that, things we need to decide on. Peter brought it up and wanted it on the list so I put it on. I can be taken off just as easily. I put Peter's name on the item, and a question mark. The open items list is just so we don't forget things. I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? ---(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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. Right, and? How many times in the past has it been the last beta in the cycle that forced the initdb? Are you able to guarantee that there *won't* be another initdb required if we wait until mid-next week? I agree, but if we _know_ we have more initdb issues to resolve (and pg_dump load issues) doesn't it make sense to at least do all of them that we have outstanding? If not, we are guaranteeing an initdb. I would rather _try_ to avoid one for beta3. -- 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: I think you are confusing the open items list with the TODO list. TODO usually has some basis, while open items is just that, things we need to decide on. Peter brought it up and wanted it on the list so I put it on. I can be taken off just as easily. I put Peter's name on the item, and a question mark. The open items list is just so we don't forget things. I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? Removed. See, I can remove them as quickly as I add them. :-) -- 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 18 Sep 2002, Bruce Momjian wrote: We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. Right, and? How many times in the past has it been the last beta in the cycle that forced the initdb? Are you able to guarantee that there won't* be another initdb required if we wait until mid-next week? I completely agree with Bruce here. Requiring an initdb for every beta release significantly reduces the number of people who will be willing to try it out -- so initdb's between betas are not disasterous, but should be avoided if possible. Since waiting till next week significantly reduces the chance of an initdb for beta3 and has no serious disadvantage that I can see, it seems the right decision to me. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
I completely agree with Bruce here. Requiring an initdb for every beta release significantly reduces the number of people who will be willing to try it out -- so initdb's between betas are not disasterous, but should be avoided if possible. But it does mean that 7.3 to 7.3 pg_dump gets a good testing... You could almost make it mandatory to have an initdb during beta :) 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: ... I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... I want to review and apply Alvaro's attisinherited fix before we go beta2. I think I can get that done tomorrow. I can't recall any other initdb-forcing fixes in the pipeline; Bruce, do you? Which is not to say we don't have a ton of known bugs to fix... I'd lean towards a Monday-ish beta2 myself. regards, tom lane ---(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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... I want to review and apply Alvaro's attisinherited fix before we go beta2. I think I can get that done tomorrow. I can't recall any other initdb-forcing fixes in the pipeline; Bruce, do you? Looking at the open item list, I see: fix up function return types on lang/type/trigger creation or loosen opaque restrictions Seems that should be fixed before beta2 because it does effect people loading data. Are we done with all of these? Add casts: (Tom) assignment-level cast specification inet - text macaddr - text int4 - varchar? int8 - varchar? add param for length check for char()/varchar() Which is not to say we don't have a ton of known bugs to fix... I'd lean towards a Monday-ish beta2 myself. Yes, I would like to get a few days of quiet before packaging beta2. -- 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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... I want to review and apply Alvaro's attisinherited fix before we go beta2. I think I can get that done tomorrow. I can't recall any other initdb-forcing fixes in the pipeline; Bruce, do you? Which is not to say we don't have a ton of known bugs to fix... I'd lean towards a Monday-ish beta2 myself. 'k, then let's go with a Sunday night packaging, Monday announce, so that we have beta2 testing starting right at the beginning of the week ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) Tke that @#$@$@@$@#$ thing out of there until its actually been fully discussed ... you are starting to remind me of Charlie Brown ... this, I think, was Thomas' whole point, in that things are added way too faster and easily without fully understanding all of the ramifications ... let a discussion cool down *before* you take things off, or add things to, the list ... --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
It is an open issue. It has to be resolved. When it is, I will remove it. I added a question mark to it but it needs to be tracked. I keep having to add and remove it because I have people telling me what to do. It was Peter who told me to add it, and you and Thomas to remove it. It isn't me adding/removing on my own. --- Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) Tke that @#$@$@@$@#$ thing out of there until its actually been fully discussed ... you are starting to remind me of Charlie Brown ... this, I think, was Thomas' whole point, in that things are added way too faster and easily without fully understanding all of the ramifications ... let a discussion cool down *before* you take things off, or add things to, the list ... --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 -- 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Thu, 19 Sep 2002, Bruce Momjian wrote: It is an open issue. It has to be resolved. When it is, I will remove it. I added a question mark to it but it needs to be tracked. I keep having to add and remove it because I have people telling me what to do. It was Peter who told me to add it, and you and Thomas to remove it. It isn't me adding/removing on my own. Right, so you have two telling you to remove it, one telling you to add it, and two that are discussion why/if it *should* be added ... Tom feels it should be added, and I'm clarifing the why of it ... don't re-add it until we've determined *if* it is actually an open issue or not ... stop jumping the gun ... --- Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) Tke that @#$@$@@$@#$ thing out of there until its actually been fully discussed ... you are starting to remind me of Charlie Brown ... this, I think, was Thomas' whole point, in that things are added way too faster and easily without fully understanding all of the ramifications ... let a discussion cool down *before* you take things off, or add things to, the list ... --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 -- 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Thu, 19 Sep 2002, Bruce Momjian wrote: It is an open issue. It has to be resolved. When it is, I will remove it. I added a question mark to it but it needs to be tracked. I keep having to add and remove it because I have people telling me what to do. It was Peter who told me to add it, and you and Thomas to remove it. It isn't me adding/removing on my own. Right, so you have two telling you to remove it, one telling you to add it, and two that are discussion why/if it *should* be added ... Tom feels it should be added, and I'm clarifing the why of it ... don't re-add it until we've determined *if* it is actually an open issue or not ... stop jumping the gun ... I will make the decision. If you want to maintain your own open items list, go ahead. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Open 7.3 items
There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. --- P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? Fix BeOS, QNX4 ports Fix AIX large file compile failure of 2002-09-11 (Andreas) Get bison upgrade on postgresql.org for ecpg only (Marc) Allow ecpg to properly handle PREPARE/EXECUTE (Michael) Fix vacuum btree bug (Tom) Fix client apps for autocommit = off Fix clusterdb to be schema-aware Change log_min_error_statement to be off by default (Gavin) Fix return tuple counts/oid/tag for rules Loading 7.2 pg_dumps fix up function return types on lang/type/trigger creation or loosen opaque restrictions functions no longer public executable languages no longer public usable Add schema dump option to pg_dump Add casts: (Tom) assignment-level cast specification inet - text macaddr - text int4 - varchar? int8 - varchar? add param for length check for char()/varchar() Create script to make proper dependencies for SERIAL and foreign keys (Rod) Fix $libdir in loaded functions? On Going Point-in-time recovery Win32 port Security audit Documentation Changes - Document need to add permissions to loaded functions and languages Move documation to gborg for moved projects -- 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] Open 7.3 items
Change log_min_error_statement to be off by default (Gavin) I will be happy to provide this simple fix once I can get some indication of the preferred implication. The discussion left off with Bruce prefering that the GUC code for the *_min_* variables be variable specific where as Tom saw no need to back out the generic assignment function I provided, despite the fact that it behaves `illogically' (client_min_messages = FATAL?). Gavin ---(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] Open 7.3 items
Tom Lane: And with the availability of schemas in 7.3, I think that multiple databases per installation is going to become less common to begin with --- people will more often use multiple schemas in one big database if they want the option of data sharing, or completely separate installations if they want airtight separation. This is not a good assumption, in my opinion. Normally, one app is associated with one database. This way, if something happens to the db, only one application is unavailable, others will not be affected, more or less. Besides, some databases are huge, so recovery time may take a long time. If everything is in one db, the whole organization will be brought to a halt, all apps will be down for a while. From my experience, this will not be considered acceptable in any reasonable organization. This is the place where cross-db queries become critically important. You do not want to duplicate data in several databases and, at the same time, you do not want to have one huge unmanageable db that can potentially bring down all your apps. my $0.02 __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
I think we need to resolve this discussion from a week ago. The current code is this: global usernames are stored just like before, e.g. postgres local users are stored as user@dbname when connecting, global users add '@' to their names when connecting, local users use just their user name, no @dbname Tom likes this because it is the fewer global users who have to append the '@'. Vince and Peter think that it should be local users adding '@' when connecting because: they have an @ sign in their name anyway global users should be able to connect unchanged I can foresee a time when we will have longer usernames, and local users will be able to connect with the full user@dbname, and we can allow user@ as a shortcut. In summary, I prefer to change the code to have local users append the '@'. Comments? It is an easy change and prevents what is a very confusing situation where we add '@' for users who don't have @, and remove '@' for users who have it. --- Peter Eisentraut wrote: Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: I'm concerned that we leave essentially no migration path, that is, the ability to turn the feature on to try it out without immediately breaking every application. Uh ... what? I fail to understand your objection. AFAICS the only apps that could be broken are scripts that have usernames hardwired into them ... I'm completely lost between all the proposals about where the @ is going to be specified, added, or removed. What happens on the client side and what happens on the server side? All I would like to see is that I can turn on this feature and nothing changes as long as I don't add any local users. Yes, that includes hard-wired user names on the client side. Of course there are various degrees of hard-wiring, but what if the ISP admin updates to 7.3 and wants to turn on the feature for new clients? Does he tell all his existing clients that they must update their user names? Possibly, these users got their database access with a shell account and don't specify the user name at all because it defaults to the OS user name. Does that continue to work? -- Peter Eisentraut [EMAIL PROTECTED] -- 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: [HACKERS] Open 7.3 items
On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: I think we need to resolve this discussion from a week ago. The current code is this: I thought it WAS resolved, to do: global usernames are stored just like before, e.g. postgres local users are stored as user@dbname when connecting, global users add '@' to their names when connecting, local users use just their user name, no @dbname Tom likes this because it is the fewer global users who have to append the '@'. At least that was my perception of the uneasy consensus reached. Basically, this tags the @ as magic saying, during the client connect process, 'I'm GLOBAL, treat me differently'. Now that I actually understand how this is supposed to work, which your four lines above elucidate nicely, I am in more agreement than I was that this is the right answer to this issue. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Open 7.3 items
Lamar Owen wrote: On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: I think we need to resolve this discussion from a week ago. The current code is this: I thought it WAS resolved, to do: global usernames are stored just like before, e.g. postgres local users are stored as user@dbname when connecting, global users add '@' to their names when connecting, local users use just their user name, no @dbname Tom likes this because it is the fewer global users who have to append the '@'. At least that was my perception of the uneasy consensus reached. Basically, this tags the @ as magic saying, during the client connect process, 'I'm GLOBAL, treat me differently'. Now that I actually understand how this is supposed to work, which your four lines above elucidate nicely, I am in more agreement than I was that this is the right answer to this issue. OK, you have now split the vote because we have two for the change, and two against. Why do you prefer to tag the globals? Is it Tom's argument? I think it is kind of strange to tag the globals when it is the locals who have @ in their username, and when they do: $ psql -U dave test Welcome to psql 7.3devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit test= select current_user; current_user -- dave@test (1 row) they will see their full username. I can go either way. I am just saying we need to hear from more people to make sure we are doing this properly. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote: Lamar Owen wrote: On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: I thought it WAS resolved, to do: Tom likes this because it is the fewer global users who have to append the ''. At least that was my perception of the uneasy consensus reached. OK, you have now split the vote because we have two for the change, and two against. Why do you prefer to tag the globals? Is it Tom's argument? I think it is kind of strange to tag the globals when it is the locals who have in their username, and when they do: I agree with what Tom said, and understand why he said it. And I thought you did, too -- I have apparently misunderstood (again!) the issue. In the local-enabled scheme, ISTM the majority of users will be local users. The goal is transparent virtual databases -- at least that's what I consider the goal. As far as the user is concerned, the other databases might as well not even exist -- all they are doing is connecting to their database. Since they have to give the database name as part of the connection, it just makes sense that they should have the closest to default behavior. In the case of a virtual hosting postmaster, global users would likely be DBA's, although they might not be. These users are going to be the exception, not the rule -- thus a character to tag their 'exceptional' nature. You may not even want your virtual host local users to realize that there is another user by that name. Thus, the standard notation is the least intrusive for the very users that need uninstrusive notation. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
It should also be noted that it's easy to get the DBAs to change their username in the future when / if the @ hack goes away BUT it will be difficult to change the usernames of the hundreds to thousands of customer accounts. For an upgrade, we'd end up making a script in the upgrade to keep them the same (with the @) then have a control panel code in place to suggest to the user that they may stop using the @ if they wish click here type of thing. Tom likes this because it is the fewer global users who have to append the '@'. At least that was my perception of the uneasy consensus reached. OK, you have now split the vote because we have two for the change, and two against. Why do you prefer to tag the globals? Is it Tom's argument? I think it is kind of strange to tag the globals when it is the locals who have @ in their username, and when they do: In the case of a virtual hosting postmaster, global users would likely be DBA's, although they might not be. These users are going to be the exception, not the rule -- thus a character to tag their 'exceptional' nature. ---(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] Open 7.3 items
OK, we have enough votes to keep the existing behavior, unless Marc appears and says he doesn't like it. ;-) Thanks. --- Rod Taylor wrote: It should also be noted that it's easy to get the DBAs to change their username in the future when / if the @ hack goes away BUT it will be difficult to change the usernames of the hundreds to thousands of customer accounts. For an upgrade, we'd end up making a script in the upgrade to keep them the same (with the @) then have a control panel code in place to suggest to the user that they may stop using the @ if they wish click here type of thing. Tom likes this because it is the fewer global users who have to append the '@'. At least that was my perception of the uneasy consensus reached. OK, you have now split the vote because we have two for the change, and two against. Why do you prefer to tag the globals? Is it Tom's argument? I think it is kind of strange to tag the globals when it is the locals who have @ in their username, and when they do: In the case of a virtual hosting postmaster, global users would likely be DBA's, although they might not be. These users are going to be the exception, not the rule -- thus a character to tag their 'exceptional' nature. -- 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: [HACKERS] Open 7.3 items
On Tue, 2002-08-27 at 21:05, Lamar Owen wrote: On Tuesday 27 August 2002 03:43 pm, Bruce Momjian wrote: Lamar Owen wrote: On Tuesday 27 August 2002 03:19 pm, Bruce Momjian wrote: I thought it WAS resolved, to do: Tom likes this because it is the fewer global users who have to append the '@'. At least that was my perception of the uneasy consensus reached. OK, you have now split the vote because we have two for the change, and two against. Why do you prefer to tag the globals? Is it Tom's argument? I think it is kind of strange to tag the globals when it is the locals who have @ in their username, and when they do: I agree with what Tom said, and understand why he said it. And I thought you did, too -- I have apparently misunderstood (again!) the issue. In the local-enabled scheme, ISTM the majority of users will be local users. The goal is transparent virtual databases -- at least that's what I consider the goal. As far as the user is concerned, the other databases might as well not even exist -- all they are doing is connecting to their database. Since they have to give the database name as part of the connection, it just makes sense that they should have the closest to default behavior. In the case of a virtual hosting postmaster, global users would likely be DBA's, although they might not be. These users are going to be the exception, not the rule -- thus a character to tag their 'exceptional' nature. You may not even want your virtual host local users to realize that there is another user by that name. Thus, the standard notation is the least intrusive for the very users that need uninstrusive notation. Has this behaviour been carried through into GRANT and REVOKE? If the object is transparency for local users, it should be possible in database test to say GRANT ... TO fred and have fred understood as fred@test. If that is the case, then I will support the current position. It follows from the objective of transparency that, when reporting a user name, local users should be reported without the database suffix, i.e., fred not fred@test. Global users should be reported with the trailing @. This should cause no problem, because we have no cross-database communication; it should be impossible for george@dummy to have any connection with database test. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C But the end of all things is at hand; be ye therefore sober, and watch unto prayer. And above all things have fervent love among yourselves; for love shall cover the multitude of sins. I Peter 4:7,8 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Bruce Momjian writes: global usernames are stored just like before, e.g. postgres local users are stored as user@dbname when connecting, global users add '@' to their names when connecting, local users use just their user name, no @dbname I'm OK with this in principle. But I must say I was quite confused because the @ symbol appears in diametrically opposite contexts: a) designate local users on the server b) designate global users in the client Perhaps I might have been less confused if meaning (b) used a different character, say username!. This might be equally confusing to the next person -- just my observation. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Tue, 2002-08-27 at 22:11, Bruce Momjian wrote: Oliver Elphick wrote: Has this behaviour been carried through into GRANT and REVOKE? If the object is transparency for local users, it should be possible in database test to say GRANT ... TO fred and have fred understood as fred@test. No changes have been made anywhere except for the username passed by the client. All reporting of user names and all administration go by their full pg_shadow username, so global user dave@ is dave in pg_shadow, and dave is dave@db1 in pg_shadow. One goal of this patch was a small footprint. That is understandable, but it means that there is an inconsistency of usage for _every_ user. You connect as postgres@ and fred, but for all other purposes - CREATE USER, GRANT, REVOKE, CURRENT_USER, etc. you will be postgres and fred@database. This seems likely to cause users confusion, don't you think? It also means that any applications which test usernames will have to be altered to strip off the @database. So it seems to me that you have achieved a small footprint within the code, but potentially at the cost of a larger impact on users. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C But the end of all things is at hand; be ye therefore sober, and watch unto prayer. And above all things have fervent love among yourselves; for love shall cover the multitude of sins. I Peter 4:7,8 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Oliver Elphick [EMAIL PROTECTED] writes: So it seems to me that you have achieved a small footprint within the code, but potentially at the cost of a larger impact on users. I don't think anyone will deny that this is a kluge. However, we are not going to resurrect the separate-password-file thing (that was a worse kluge, especially when used for this purpose), and we are not going to postpone 7.3 while we think about a nicer solution. So, simple is beautiful for now. If there are enough people actually *using* this feature to make it worth improving, we can improve it ... later. 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] Open 7.3 items
Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps I might have been less confused if meaning (b) used a different character, say username!. Well, maybe ... but do we want to create two special characters in usernames, instead of one? @ still has to be considered special in incoming usernames, else you have no security against local users connecting to other databases. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Tue, 2002-08-27 at 22:44, Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: So it seems to me that you have achieved a small footprint within the code, but potentially at the cost of a larger impact on users. I don't think anyone will deny that this is a kluge. However, we are not going to resurrect the separate-password-file thing (that was a worse kluge, especially when used for this purpose), and we are not going to postpone 7.3 while we think about a nicer solution. So, simple is beautiful for now. If there are enough people actually *using* this feature to make it worth improving, we can improve it ... later. Could we then have a TODO item: * Make local and global user representation consistent throughout. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C But the end of all things is at hand; be ye therefore sober, and watch unto prayer. And above all things have fervent love among yourselves; for love shall cover the multitude of sins. I Peter 4:7,8 ---(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] Open 7.3 items
Oliver Elphick [EMAIL PROTECTED] writes: Could we then have a TODO item: * Make local and global user representation consistent throughout. That's hardly an appropriately expansive TODO item. I prefer * Provide a real solution for database-local users ;-) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: Could we then have a TODO item: * Make local and global user representation consistent throughout. That's hardly an appropriately expansive TODO item. I prefer * Provide a real solution for database-local users I say let's get it out in the field and see what people ask for. For all we know, they may be very happy with this, nor not use it at all. -- 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: [HACKERS] Open 7.3 items
Peter Eisentraut wrote: Bruce Momjian writes: global usernames are stored just like before, e.g. postgres local users are stored as user@dbname when connecting, global users add '@' to their names when connecting, local users use just their user name, no @dbname I'm OK with this in principle. But I must say I was quite confused because the @ symbol appears in diametrically opposite contexts: a) designate local users on the server b) designate global users in the client Perhaps I might have been less confused if meaning (b) used a different character, say username!. This might be equally confusing to the next person -- just my observation. There is no question it is 100% confusing. You are not alone. What keeps us from unconfusing it is the desire to make local usernames clean looking, I think. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
I'd have thought that if a matching user couldn't be found in the specified database then it would default to searching through the global users? Would be more intuitive... Lee. Bruce Momjian writes: Sample run: $ psql -U postgres test psql: FATAL: user postgres@test does not exist $ psql -U postgres@ test Welcome to psql 7.3devel, the PostgreSQL interactive terminal. ---(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] Open 7.3 items
On Sat, Aug 17, 2002 at 11:08:45PM -0400, Bruce Momjian wrote: integrate or move to gborg libpqxx, Pg:DBD It's no longer my CVS home tree... Is there something I can/should do for this? Jeroen ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Tom Lane writes: BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. I'm missing how hard it is to change last character of username is @ to no @ in username. This would seem to be a two-line change somewhere. I'm concerned that we leave essentially no migration path, that is, the ability to turn the feature on to try it out without immediately breaking every application. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Open 7.3 items
Peter Eisentraut [EMAIL PROTECTED] writes: I'm concerned that we leave essentially no migration path, that is, the ability to turn the feature on to try it out without immediately breaking every application. Uh ... what? I fail to understand your objection. AFAICS the only apps that could be broken are scripts that have usernames hardwired into them ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
On Sat, 17 Aug 2002, Bruce Momjian wrote: OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. That removes some of the uglification, I think. Then why was it when I mentioned global users not having the @ you shot it down as not possible? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Sat, 17 Aug 2002, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. No, *that* would be backwards. In installations that are using this feature, the vast majority of the users are going to be local ones. And the global users will be the presumably-more-sophisticated admins. Putting the onus of the '@' decoration on the local users instead of the global ones is exactly the wrong way to go. Unsophisticated users is hardly a reason. After all they do have an @ in their email address. If they're told the username is foo@ then their username is foo@. What's so difficult about that? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.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
Re: [HACKERS] Open 7.3 items
Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: I'm concerned that we leave essentially no migration path, that is, the ability to turn the feature on to try it out without immediately breaking every application. Uh ... what? I fail to understand your objection. AFAICS the only apps that could be broken are scripts that have usernames hardwired into them ... I'm completely lost between all the proposals about where the @ is going to be specified, added, or removed. What happens on the client side and what happens on the server side? All I would like to see is that I can turn on this feature and nothing changes as long as I don't add any local users. Yes, that includes hard-wired user names on the client side. Of course there are various degrees of hard-wiring, but what if the ISP admin updates to 7.3 and wants to turn on the feature for new clients? Does he tell all his existing clients that they must update their user names? Possibly, these users got their database access with a shell account and don't specify the user name at all because it defaults to the OS user name. Does that continue to work? -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Open 7.3 items
Peter Eisentraut [EMAIL PROTECTED] writes: I'm completely lost between all the proposals about where the @ is going to be specified, added, or removed. What happens on the client side and what happens on the server side? Well, the way things stand as of CVS tip is that (assuming you have this feature turned on in postgresql.conf): * If a connection request has a username with a trailing '@' (and no embedded '@'), then the '@' is stripped and connection proceeds. * Otherwise, '@dbname' is appended to the given username and connection proceeds. So a global user foo has to say username=foo@ in his connection request, but he's just foo in pg_shadow. A local user foo has to say foo in his connection request, and he's foo@somedb in pg_shadow. All I would like to see is that I can turn on this feature and nothing changes as long as I don't add any local users. Yes, that includes hard-wired user names on the client side. Well, we could have that by inverting the use of '@'; but as I commented before, it makes more sense to me to make the global users say '@' than to make the local users do so, because I think in an installation that wants this feature there will be lots more local than global users. I really don't put that much weight on the compatibility argument you make --- not that I don't see your point, but that I don't think it outweighs convenience of day-to-day use after one has gotten the system set up. (Also, compatibility cuts both ways: it seems just as likely to me that the clients with hardwired usernames are going to be ones you want to connect as local users, as that they are going to be ones you want to connect as global users. Maybe more likely, if you grant the assumption that there will be more local than global users.) It might be worth recalling the reason that we are going through this pushup in the first place: Marc wants to be able to assign the same username to two different users who want to access two different databases. If he would be happy with the answer give them two different usernames, we'd not be having this discussion at all. Do you think he will be happy with the answer you can give them the same username as long as it ends in '@'? I think it's highly unlikely that he'll be satisfied with that --- he wants to *not* have constraints on the names he gives out for local users. Of course there are various degrees of hard-wiring, but what if the ISP admin updates to 7.3 and wants to turn on the feature for new clients? Does he tell all his existing clients that they must update their user names? Possibly, these users got their database access with a shell account and don't specify the user name at all because it defaults to the OS user name. Does that continue to work? It works great if the ISP intends to make them all local users, which seems more likely to me than the other case. regards, tom lane ---(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] Open 7.3 items
[EMAIL PROTECTED] (Tom Lane) wrote * If a connection request has a username with a trailing '@' (and no embedded '@'), then the '@' is stripped and connection proceeds. * Otherwise, '@dbname' is appended to the given username and connection proceeds. snip It might be worth recalling the reason that we are going through this pushup in the first place: Marc wants to be able to assign the same username to two different users who want to access two different databases. If he would be happy with the answer give them two different usernames, we'd not be having this discussion at all. Do you think he will be happy with the answer you can give them the same username as long as it ends in '@'? I think it's highly unlikely that he'll be satisfied with that --- he wants to *not* have constraints on the names he gives out for local users. What about usernames that have trailing or embedded @'s? I mean you are eseentially making the @ a magic character. I admit I havent looked at the source, but doesnt this method effectively put a constraint on the use of @? What if an isp, that could use this feature, already has usernames with @'s in them (say a customers email address, etc)? Will they need to assign all new usernames to make this thing function? What if you want to give one person (one username) access to 2 db's? Does that mean, under the current scheme, that the two accounts you create can have the same username but have different passwords? What if you want to erase the one account (do you have to remember to erase all n accounts you created with the same username, or all n except the ones that were never mean to be the same person but share the same username)? Normally a user has a unique name. Does anyone see a problem if/when the whole db access thing becomes part of the privileges system? If you implement the multiple users same username, then you'll have to reassign all but one of the users to new usernames. ---(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] Open 7.3 items
OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. That removes some of the uglification, I think. --- Tom Lane wrote: BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. regards, tom lane -- 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: [HACKERS] Open 7.3 items
Bruce Momjian [EMAIL PROTECTED] writes: OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. No, *that* would be backwards. In installations that are using this feature, the vast majority of the users are going to be local ones. And the global users will be the presumably-more-sophisticated admins. Putting the onus of the '@' decoration on the local users instead of the global ones is exactly the wrong way to go. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, I think we are doing this backwards. Instead of adding '@' to global users, and then removing it in the backend, why don't we have local users end with '@', that way, global users continue to connect just as they have before, and local users connect with @, so dave@db1 connects as 'dave@' and if he has other database access, he can use the same 'dave@' name. No, *that* would be backwards. In installations that are using this feature, the vast majority of the users are going to be local ones. And the global users will be the presumably-more-sophisticated admins. Putting the onus of the '@' decoration on the local users instead of the global ones is exactly the wrong way to go. OK, but it looks slightly less ugly. -- 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] Open 7.3 items
Bruce Momjian [EMAIL PROTECTED] writes: OK, here is the patch with the suggested changes. I am sending the patch to hackers because there has been so much interest in this. One minor gripe: + /* If user@, it is a global user, remove '@' */ + if (strchr(port-user, '@') == port-user + strlen(port-user)-1) This code is correct, but it tempts someone to replace the strchr() with a single-character check on the last character of the string. Which would introduce the security hole we discussed before. The code is okay, but *please* improve the comment to point out that you are also excluding the case where there are @'s to the left of the last character. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
OK, applied, with that change. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, here is the patch with the suggested changes. I am sending the patch to hackers because there has been so much interest in this. One minor gripe: + /* If user@, it is a global user, remove '@' */ + if (strchr(port-user, '@') == port-user + strlen(port-user)-1) This code is correct, but it tempts someone to replace the strchr() with a single-character check on the last character of the string. Which would introduce the security hole we discussed before. The code is okay, but *please* improve the comment to point out that you are also excluding the case where there are @'s to the left of the last character. regards, tom lane -- 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])
[HACKERS] Open 7.3 items
As you can see, the open items list is greatly shrunk. We have two weeks to go and most of these seems do-able, except for point-in-time recovery, which may not make it. I haven't heard anything recently on it. Would someone put together a porting document for schema changes and drop column changes? --- P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- Point-in-time recovery - status? (J.R., Richard) Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? ecpg and bison issues - solved? (Michael) have pg_dumpall dump out db privilege and per-user/db settings fix implicit type coercions that are worse Prepared statements - to be reviewed (Tom) improve macros in new tuple header code (Tom) integrate or move to gborg libpqxx, Pg:DBD Allow PL/PgSQL functions to return sets (Neil) Allow easy display of usernames in a group (pg_hba.conf uses groups now) fix BeOS and QNX4 ports Documentation Changes - Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables Document need to add permissions to loaded functions and languages -- 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: [HACKERS] Open 7.3 items
On Thu, 15 Aug 2002, Bruce Momjian wrote: I have seen some negative reactions to the feature. I am willing to ask for a vote, if that is what people want. If not, I will apply the patch in the next day or two. So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The more we discuss it the worse it looks. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Vince Vielhaber [EMAIL PROTECTED] writes: So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The trouble with putting it in contrib is that that makes it effectively unavailable to anyone who installs from RPMs, or otherwise doesn't build from source for themselves. Putting a patch diff in contrib is a bad idea anyway since the patch will suffer bit-rot in no time, as the referenced files change. Since the patch is small and doesn't change behavior or performance if you don't enable the feature, I don't think there's a good reason to push it off to contrib just because it's ugly. The more we discuss it the worse it looks. I still like the other way better --- but I'm still not prepared to do the legwork to make it happen, so I have to defer to whatever Bruce is willing to implement. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items, with names
Bruce Momjian [EMAIL PROTECTED] writes: Reindex/btree shrinkage - does reindex need work, can btree be shrunk? I think there is zero probability that anything will be finished on this in the next two weeks, considering that (a) no one is working on it, and (b) it's not a small task. Push it back to TODO. Schema handling - ready? interfaces? client apps? You can put my name on this for backend, psql, and pg_dump issues. I am not sure what needs to be done in the other client-side code. improve macros in new tuple header code (Manfred) Since I was the one griping, not Manfred, it's probably my job to fix this. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
On Fri, 16 Aug 2002, Tom Lane wrote: Vince Vielhaber [EMAIL PROTECTED] writes: So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The trouble with putting it in contrib is that that makes it effectively unavailable to anyone who installs from RPMs, or otherwise doesn't build from source for themselves. Putting a patch diff in contrib is a bad idea anyway since the patch will suffer bit-rot in no time, as the referenced files change. RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Vince Vielhaber writes: [ 'user@' patch ] whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Having read bits and pieces of this thread, can those in favour confirm that this would be an effect of this patch? If so I fail to see the usefulness of this and indeed it would be very harmful to existing installations! All use of PostgreSQL utilities in scripts for our product always do a '-U sprint' to use a global user, this aids our internal development and makes installation notes for clients easier... Also what effect would adding significance to '@' in the context of usernames have, if any, on the current use of it as a database/host separator (in ECPG, certainly would be useful in the utilities too)? Thanks, Lee. ---(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] Open 7.3 items
Lee Kindness [EMAIL PROTECTED] writes: Vince Vielhaber writes: [ 'user@' patch ] whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Having read bits and pieces of this thread, can those in favour confirm that this would be an effect of this patch? I think Vince is talking through his hat. The proposed flag wouldn't ever be enabled by default. If someone did turn it on in their installation on a whim, they'd soon turn it off again if they didn't like the effects. I do not see much difference between the above argument and arguing we shouldn't have i18n support, because if I turned it on on a whim I wouldn't be able to read my error messages. Once again: *no one* has at any time suggested that any form of this patch should affect the default behavior in the slightest. Also what effect would adding significance to '@' in the context of usernames have, if any, on the current use of it as a database/host separator (in ECPG, certainly would be useful in the utilities too)? Well, I don't see any difficulty there, but if you are aware of a context where it'd be a problem, point it out! regards, tom lane ---(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] Open 7.3 items
On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. So, Vince, do you have problems with the various GUC based optimizer hooks getting set to other than the default? I'd think you'd notice if suddenly indexscans all went away, or any of these: #enable_seqscan = true #enable_indexscan = true #enable_tidscan = true #enable_sort = true #enable_nestloop = true #enable_mergejoin = true #enable_hashjoin = true My point is that your resistance to a GUC controlled runtime configurable on the basis of 'it might get changed accidently' makes little sense to me, given all the other runtime config settings that never do get changed. What makes you think this one will be more susceptible to accidental flipping? I'm not sure who's 'whim' it is that your afraid of: perhaps you have a paticularly sadistic DBA to deal with? ;-) And of course, this being free software and all, noone is forcing an upgrade on you. Ross ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
On Fri, 2002-08-16 at 09:51, Ross J. Reedstrom wrote: On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. So, Vince, do you have problems with the various GUC based optimizer hooks getting set to other than the default? I'd think you'd notice if suddenly indexscans all went away, or any of these: #enable_seqscan = true #enable_indexscan = true #enable_tidscan = true #enable_sort = true #enable_nestloop = true #enable_mergejoin = true #enable_hashjoin = true My point is that your resistance to a GUC controlled runtime configurable on the basis of 'it might get changed accidently' makes little sense to me, given all the other runtime config settings that never do get changed. What makes you think this one will be more susceptible to accidental flipping? I'm not sure who's 'whim' it is that your afraid of: perhaps you have a paticularly sadistic DBA to deal with? ;-) And of course, this being free software and all, noone is forcing an upgrade on you. AND, I thought the general consensus was **AWAY** from configure time directives and to GUC variables whenever **POSSIBLE**. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items, with names
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Reindex/btree shrinkage - does reindex need work, can btree be shrunk? I think there is zero probability that anything will be finished on this in the next two weeks, considering that (a) no one is working on it, and (b) it's not a small task. Push it back to TODO. Done. Also, we do now have contrib/reindexdb, so it is there for people to use until we get it fixed. That is a step forward, and it is a documented problem in 7.3 too. Schema handling - ready? interfaces? client apps? You can put my name on this for backend, psql, and pg_dump issues. I am not sure what needs to be done in the other client-side code. I am worried about the other stuff. I just added DROP COLUMN to the open items list to make sure that is dealt with too. improve macros in new tuple header code (Manfred) Since I was the one griping, not Manfred, it's probably my job to fix this. OK, but I thought Manfred was going to address this when he got back from vacation, but he is back now. I assume you are saying that he isn't quite sure what you want and that you will have to do it. OK. -- 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: [HACKERS] Open 7.3 items
Vince Vielhaber wrote: On Thu, 15 Aug 2002, Bruce Momjian wrote: I have seen some negative reactions to the feature. I am willing to ask for a vote, if that is what people want. If not, I will apply the patch in the next day or two. So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The more we discuss it the worse it looks. I can do a vote. However, seeing many positive comments about the patch, and 1-2 negative ones (with no suggestion on how to improve it), I don't think the negative votes will win. I usually do a vote when the email comments are coming in kind of close. Specifically, in the thread, I have Vince and Peter as negative, and 7 positive, I think. Look at the contraints I am under to implement what is effectively username schemas: small patch, no bloat, because it isn't a core feature multiple global users no namespace collisions between global/non-global users zero performance impact 32-byte user string coming from the client Specifically, what is ugly about it? Is it that global users have an @ at the end of their names? How do we prevent namespace collisions _without_ doing this? I am all ears. -- 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] Open 7.3 items: heap tuple header
On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: P O S T G R E S Q L 7 . 3 O P E NI T E M S improve macros in new tuple header code (Manfred) ISTM there's no consensus about what improve means. I tried to start discussing this after my vacation, but apparently people had better things to do. On Wed, 07 Aug 2002 16:16:14 +0200, I wrote (Heap tuple header issues): :. Transaction and command ids, performance : :I offered to provide cheaper versions of GetCmin and GetCmax to be :used by the tqual routines. These version would reduce additional CPU :work from two infomask compares to one. Is this still considered an :issue? However, I don't think this would lead to any measurable difference. :. Transaction and command ids, robustness : :I'm still of the opinion that putting *more* knowledge into the SetXxx :macros is the way to go. The runaway INSERT bug could as well have :been fixed by changing SetCmax to do nothing, if HEAP_XMAX_INVALID is :set, and changing SetXmaxInvalid to set HEAP_XMAX_INVALID. Likewise I :would change SetXmax to set HEAP_XMAX_INVALID, if xid == :InvalidTransactionId, or reset it, if != (not sure about this). Same :for SetXminInvalid and SetXmin. This is the main point of disagreement: Tom Lane wants lighter macros, I want heavier macros. Which direction shall we go? :Further, I'll try to build a regression test using statement timeout :to detect runaway INSERT/UPDATE (the so called halloween problem). This won't hurt anyway. I'll start working on this. BTW, my changes have been criticized with words like vague unease, zero confidence, very obviously not robust, do not trust the current code at all etc., while from day one all my patches have passed all regression tests. This makes me wonder whether there is something wrong with the regression tests ... :. Oids : :I was a bit surprised that these patches went in so smoothly, must be :due to the fact that there was a lot of work to do at that time. :Personnally I feel that these changes are more dangerous than the :Xmin/Cid/Xmax patches; and I ask the hackers to review especially :part 2, which contains changes to the executor and even to bootstrap. :. Oids, t_infomask : :There has been no comment from a tool developer. :. Oids, heap_getsysattr : :We thought that a TupleDesc parameter would have to be added for this :function. However, tests showed that heap_getsysattr is not called to :get the oid, when the tuple doesn't have an oid: ERROR: Attribute :'oid' not found. :. Oids, micro tuning : :There are a few places, where storing an oid in a local variable might :be a little faster than fetching it several times from a heap tuple :header. However, I don't think this would lead to any measurable difference. :. Overall performance : :If Joe Conway can be talked into running OSDB benchmarks with old and :new heap tuple header format, I'll provide patches and instructions to :easily switch between versions. Or, Joe, can you tell me, what I need :to have and need to do to set up a benchmarking environment? With Joe's help (thanks again, Joe) I've managed to setup a benchmarking environment and I am continuously testing different configurations for a week now. There are issues with OSDB which I plan to bring up later when things cool down, but a first anawhat seems to show that with the reduced heap tuple header size we get a speed improvement of up to 3%, especially when the database is significantly larger than system memory. When the database size is only a small fraction of available memory, results vary so widely that I cannot tell whether the new heap tuple macros are a loss or a win. : :. CVS : :There have been a lot of CVS broken messages in the past few days. :When I tried : cvs -z3 log heapam.c :I got :| cvs server: failed to create lock directory for :`/projects/cvsroot/pgsql/src/backend/access/heap' :(/projects/cvsroot/pgsql/src/backend/access/heap/#cvs.lock): No such file or directory :| cvs server: failed to obtain dir lock in repository :`/projects/cvsroot/pgsql/src/backend/access/heap' :| cvs [server aborted]: read lock failed - giving up : :Is this a temporary problem or did a miss any planned changes? AFAIK I have to re-checkout everything. Servus Manfred ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items: heap tuple header
Manfred Koizar wrote: On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: P O S T G R E S Q L 7 . 3 O P E NI T E M S improve macros in new tuple header code (Manfred) ISTM there's no consensus about what improve means. I tried to start discussing this after my vacation, but apparently people had better things to do. OK. On Wed, 07 Aug 2002 16:16:14 +0200, I wrote (Heap tuple header issues): :. Transaction and command ids, performance : :I offered to provide cheaper versions of GetCmin and GetCmax to be :used by the tqual routines. These version would reduce additional CPU :work from two infomask compares to one. Is this still considered an :issue? However, I don't think this would lead to any measurable difference. Yep. :. Transaction and command ids, robustness : :I'm still of the opinion that putting *more* knowledge into the SetXxx :macros is the way to go. The runaway INSERT bug could as well have :been fixed by changing SetCmax to do nothing, if HEAP_XMAX_INVALID is :set, and changing SetXmaxInvalid to set HEAP_XMAX_INVALID. Likewise I :would change SetXmax to set HEAP_XMAX_INVALID, if xid == :InvalidTransactionId, or reset it, if != (not sure about this). Same :for SetXminInvalid and SetXmin. This is the main point of disagreement: Tom Lane wants lighter macros, I want heavier macros. Which direction shall we go? Could you or Tom explain that in a way that others could understand. My guess is that you want the sanity checks in the macros, and Tom wants more of them in the main code? :Further, I'll try to build a regression test using statement timeout :to detect runaway INSERT/UPDATE (the so called halloween problem). This won't hurt anyway. I'll start working on this. BTW, my changes have been criticized with words like vague unease, zero confidence, very obviously not robust, do not trust the current code at all etc., while from day one all my patches have passed all regression tests. I totally agree with you here. You code has been great, and it did something (reduce tuple size) that no one else thought possible. This makes me wonder whether there is something wrong with the regression tests ... However, I should add that the regression tests test only a small subset of how the database has to operate. There are so many bizarre conditions that we can't test them all. -- 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] Open 7.3 items
Bruce Momjian [EMAIL PROTECTED] writes: Specifically, what is ugly about it? Is it that global users have an @ at the end of their names? How do we prevent namespace collisions _without_ doing this? I am all ears. The folks who are unhappy about this design basically think that the namespace collisions issue should not be considered a vital requirement; whereupon you don't have to have the '@' because a search in the pg_shadow flat file would work well enough. It comes down to a judgment call about which is uglier, putting '@' on global usernames or having to avoid namespace collisions. At this point I think we've wasted more than enough time on the argument; I haven't seen any new ideas recently, nor any change in anyone's position. Since no one seems to want to do the work to make a better implementation, I vote we accept the patch we have and move on. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Fri, 16 Aug 2002, Tom Lane wrote: Lee Kindness [EMAIL PROTECTED] writes: Vince Vielhaber writes: [ 'user@' patch ] whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Having read bits and pieces of this thread, can those in favour confirm that this would be an effect of this patch? I think Vince is talking through his hat. The proposed flag wouldn't ever be enabled by default. If someone did turn it on in their installation on a whim, they'd soon turn it off again if they didn't like the effects. I do not see much difference between the above argument and arguing we shouldn't have i18n support, because if I turned it on on a whim I wouldn't be able to read my error messages. Once again: *no one* has at any time suggested that any form of this patch should affect the default behavior in the slightest. Not yet they haven't. What happens when it's decided that this *feature* is a good thing and should be the default? Maybe not now, but can you guarantee that that won't happen in say 7.4? Or maybe 8.0? I can hear it now, Well we're giving you an entire version to change your scripts. There's not even a concensus that this is the right way to do it, you even said you'd prefer it was implemented in another way but don't have the time to do it. Since when does this group rush to stuff features in without agreement even on HOW to implement it? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Vince Vielhaber wrote: Once again: *no one* has at any time suggested that any form of this patch should affect the default behavior in the slightest. Not yet they haven't. What happens when it's decided that this *feature* is a good thing and should be the default? Maybe not now, but can you guarantee that that won't happen in say 7.4? Or maybe 8.0? I can hear it now, Well we're giving you an entire version to change your scripts. I can't argue hypothetical with you, but if we decided to make this a default behavior, we would probably push the functionality down into CREATE USER, create a new column in pg_shadow, lengthen the username passed from the client, and do it that way. However, because it is not on by default _and_ we don't want to add visibility to a functionality that is off by default, we are doing it this way. Remember, non-local users already have an @ in their username. I am just adding @ to the global users too. This functionality actually allows you to keep your old users in pg_shadow and once you turn on the feature, those users become unusable. When you turn the feature off, they are back again. I know the trailing @ is ugly, but it prevents surpises when connecting to the database. There's not even a consensus that this is the right way to do it, you even said you'd prefer it was implemented in another way but don't have the time to do it. Since when does this group rush to stuff features in without agreement even on HOW to implement it? This is an argument I don't want to bow to. How many features have we left undone, for release after release, because we couldn't find a perfect way to do it, so we did nothing, and users went elsewhere for their database needs? We have had enough discussion to know that there isn't a perfect solution in this case, so we are going to implement the best we can, and if we have to revisit it in 8.0, so be it. I am sure you will still be around to help craft that solution. -- 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] Open 7.3 items
On Fri, 16 Aug 2002, Ross J. Reedstrom wrote: On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. So, Vince, do you have problems with the various GUC based optimizer hooks getting set to other than the default? I'd think you'd notice if suddenly indexscans all went away, or any of these: #enable_seqscan = true #enable_indexscan = true #enable_tidscan = true #enable_sort = true #enable_nestloop = true #enable_mergejoin = true #enable_hashjoin = true My point is that your resistance to a GUC controlled runtime configurable on the basis of 'it might get changed accidently' makes little sense to me, given all the other runtime config settings that never do get changed. What makes you think this one will be more susceptible to accidental flipping? My point has nothing to do with resistance to GUC configurables. Someone WILL decide that having it as a default is a *Good Thing* because it's there and is useful to them and in its current implementation there's not even a concensus that it's the right way to do it. It's being rushed into this version unnecessarily. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Vince Vielhaber [EMAIL PROTECTED] writes: My point has nothing to do with resistance to GUC configurables. Someone WILL decide that having it as a default is a *Good Thing* because it's there and is useful to them Which someone would this be? There's no chance that such a proposal would pass a pghackers vote, and certainly no chance that someone could commit such a change into CVS without everyone noticing. and in its current implementation there's not even a concensus that it's the right way to do it. It's being rushed into this version unnecessarily. It's being rushed into this version because we need a stopgap solution. I don't see it as anything but a stopgap. The fact that it's a very small patch is good, because it can be replaced with minimal effort once someone has the time to design and implement a better mechanism for multi-database user management. AFAICT a proper solution will involve considerable work, and I don't see it happening in time for 7.3. Also, ugly as this may be, it's still better than the old solution for people who are trying to support multiple similarly-named users in different databases. The old hack required external password files which mean manual management, admin involvement in any password change, etc. With this approach users can set their password normally even if they're being restricted to one database. So realistically I think this does not affect people who aren't using it, and for people who do want to use it it's a step forward, even if not as far forward as we'd like. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. 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] Open 7.3 items
Tom Lane wrote: BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Sure. If I can get one more 'yes' I will submit a new patch with the change. It does prevent the namespace collision without mucking up pg_shadow. We only need to tell people that global users need to supply their username to the client as user@. Is that cleaner? Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. Ewe, I didn't think of that. Good point. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Fri, 2002-08-16 at 20:03, Bruce Momjian wrote: Sure. If I can get one more 'yes' I will submit a new patch with the change. It does prevent the namespace collision without mucking up pg_shadow. We only need to tell people that global users need to supply their username to the client as user@. Is that cleaner? I will vote yes for this change. I think the flexibility this new system offers will make it much easier for people to offer PostgreSQL hosting facilities, of which I would like to see many more. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C And whatsoever ye shall ask in my name, that will I do, that the Father may be glorified in the Son. John 14:13 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items: heap tuple header
On Fri, 16 Aug 2002 12:25:37 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: Manfred Koizar wrote: This is the main point of disagreement: Tom Lane wants lighter macros, I want heavier macros. Which direction shall we go? Could you or Tom explain that in a way that others could understand. I'm not sure we understand each other :-) My guess is that you want the sanity checks in the macros, and Tom wants more of them in the main code? I guess we agree on having the sanity checks in the macros. It's more on what the macros are allowed to change and what decisions they are allowed to take. Do the following quotes make it clearer? :On Sat, 20 Jul 2002 16:27:14 -0400, Tom Lane [EMAIL PROTECTED] :wrote: :I'd recommend redesigning the HeapTupleHeaderSet macros so that they :do not do any setting of t_infomask bits, or even take any conditional :action based on them, to which I replied on Sun, 21 Jul 2002 23:00:22 +0200: :The HEAP_XMIN_IS_XMAX bit is exclusively managed by these macros. :Pulling the handling of this bit out of the macros and spreading it to :the places, where the macros are used, cannot make the whole thing :more robust. This would mean, the caller had to decide whether to :store Cmax into t_cid or t_xmax... Tom: : but solely Assert() that the bits are already :in the appropriate state to allow storing of the value to be stored. :Then, all uses have to be checked to ensure that t_infomask is coerced :into the right state *before* doing HeapTupleHeaderSetFoo. me: :Apart from HEAP_XMIN_IS_XMAX this was my intention; we already do :this with HEAP_MOVED. I could add an assertion to SetCmax: : Assert(!((tup)-t_infomask HEAP_XMAX_INVALID)); : :OTOH I thought about putting *more* logic into the macros to make :their use less fragile. For example SetXmaxInvalid could set the :HEAP_XMAX_INVALID bit, likewise SetCminInvalid with XMIN_INVALID. BTW, my changes have been criticized with words like vague unease, zero confidence, very obviously not robust, do not trust the current code at all etc., while from day one all my patches have passed all regression tests. I totally agree with you here. You code has been great, and it did something (reduce tuple size) that no one else thought possible. Thanks a lot! But I was not fishing for compliments, I was just preparing for the next sentence: There is something wrong with the regression tests. In fact vague unease more than once was a proper description for my own feelings when I posted a patch, because I didn't know whether I could trust the tests. If core developers share this unease, I find myself in good company. This makes me wonder whether there is something wrong with the regression tests ... However, I should add that the regression tests test only a small subset of how the database has to operate. So, please, could you add to TODO: * Add more regression tests There are so many bizarre conditions that we can't test them all. When Tom Lane recently posted a way to reproduce a bug (No one parent tuple was found, CASE 1) I thought about how to add this case to the regression tests, but we have no vehicle for testing concurrent transactions. TODO: * Build a test vehicle for concurrent transactions * Add even more regression tests Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
[EMAIL PROTECTED] (Bruce Momjian) wrote I know the trailing @ is ugly, but it prevents surpises when connecting to the database. if you would make the magic character a variable then perhaps you could prevent the ugly... if/when you turn off the feature, you could set the PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty string instead of a @, when you want to turn it back on, set the variable back to '@'... and if you change the character, well dont.. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Bruce Momjian) wrote I know the trailing @ is ugly, but it prevents surpises when connecting to the database. if you would make the magic character a variable then perhaps you could prevent the ugly... if/when you turn off the feature, you could set the PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty string instead of a @, when you want to turn it back on, set the variable back to '@'... and if you change the character, well dont.. It already does that. When it is off, it works just like it does in 7.2. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
OK, here is the patch with the suggested changes. I am sending the
patch to hackers because there has been so much interest in this.
---
Tom Lane wrote:
BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness. Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding. Then we would
have:
global users appear in pg_shadow as foo
local users appear in pg_shadow as foo@db
and what this would mean is that you can flip between feature-enabled
and feature-disabled states without breaking your global logins. So you
don't need the extra step of creating a postgres@ before turning on
the feature. (Which was pretty ugly anyway, since even though postgres@
could be made a superuser, he wouldn't be the same user as postgres ---
this affects table ownership, for example, and would be a serious issue
if you wanted any non-superuser global users.)
I suppose some might argue that having to say postgres@ to log in,
when your username is really just postgres as far as you can see in the
database, is a tad confusing. But the whole thing is an acknowledged
wart anyway, and I think getting rid of the two problems mentioned above
is worth it.
Also, if we do this then it's important to strip a trailing '@' only
if it's the *only* one in the given username. Else a local user
'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
with requested database db2. But I can't see any other security hole.
regards, tom lane
--
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
Index: doc/src/sgml/runtime.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml 15 Aug 2002 14:26:15 - 1.125
--- doc/src/sgml/runtime.sgml 17 Aug 2002 04:14:34 -
***
*** 1191,1196
--- 1191,1216
/varlistentry
varlistentry
+ termvarnameDB_USER_NAMESPACE/varname (typeboolean/type)/term
+ listitem
+para
+ This allows per-database user names. You can create users as literal
+ username@dbname/. When literalusername/ is passed by the client,
+ literal@/ and the database name is appended to the user name and
+ that database-specific user name is looked up by the server.
+ When creating user names containing literal@/, you will need
+ to quote the user name.
+/para
+para
+ With this option enabled, you can still create ordinary global
+ users. Simply append literal@/ when specifying the user name
+ in the client. The literal@/ will be stripped off and looked up
+ by the server.
+/para
+ /listitem
+ /varlistentry
+
+ varlistentry
indexterm
primarydeadlock/primary
secondarytimeout/secondary
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c20 Jun 2002 20:29:28 - 1.82
--- src/backend/libpq/auth.c17 Aug 2002 04:14:35 -
***
*** 117,123
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port-user, auth_data.pname, SM_USER) != 0)
{
elog(LOG, pg_krb4_recvauth: name \%s\ != \%s\,
port-user, auth_data.pname);
--- 117,123
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port-user, auth_data.pname, SM_DATABASE_USER) != 0)
{
elog(LOG, pg_krb4_recvauth: name \%s\ != \%s\,
port-user, auth_data.pname);
***
*** 290,296
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port-user, kusername, SM_USER))
{
elog(LOG, pg_krb5_recvauth: user name \%s\ != krb5 name \%s\,
port-user, kusername);
--- 290,296
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port-user, kusername, SM_DATABASE_USER))
{
elog(LOG, pg_krb5_recvauth: user name \%s\ != krb5 name \%s\,
port-user, kusername);
Index: src/backend/postmaster/postmaster.c
Re: [HACKERS] Open 7.3 items
Sample run: $ psql -U postgres test psql: FATAL: user postgres@test does not exist $ psql -U postgres@ test Welcome to psql 7.3devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit test= --- Tom Lane wrote: BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. regards, tom lane -- 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: [HACKERS] Open 7.3 items
Joe Conway wrote: Hannu Krosing wrote: What about functions 1. split(text,text,int) returns text 2. split(text,text) returns text[] and why not 3. split(text,text,text) returns text which returns text from $1 delimited by $2 and $3 Given the time remaining before beta, I'll be happy just to get #1 done. I can see the utility of #2 (or perhaps even a table function which breaks the string into individual rows). I'm not sure I understand #3. I am concerned about the name though -- only in that there are usually objections raised to function names that are too likely to conflict with user created function names. But split is good from the standpoint that it is used in other languages, so people should find it familiar. Anyone have comments on the name? Actually, I've been wondering if it wouldn't be a good idea with schemas coming to think now about how to divide up namespaces for all sorts of things, including PostgreSQL's built in functions, the contrib code, etc. I think a naming scheme with which both PostgreSQL and the community would comply, a la Java's reverse DNS scheme for namespaces would be neat. So when a database is installed, the following schemas are automatically created: org.postgresql.system - System tables and core functions org.postgresql.text - Text related functions org.postgresql.math - Math related functions org.postgresql.fts - Full-Text schema or perhaps: org.postgresql.contrib.fts - Full-Text schema etc. I don't even know if . is allowed in the schema names, but you get the idea. Then, a users search_path (or whatever it's called, I haven't used the development version in a while), would be the equivalent of Java's import statement, or C++'s using statement. So split would be a function in the org.postgresql.text schema. How about them apples? If this is an insane idea, its 3:32 A.M. my time ;-) Mike Mascari [EMAIL PROTECTED] 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] Open 7.3 items
Mike Mascari [EMAIL PROTECTED] writes: I don't even know if . is allowed in the schema names, It isn't, and we couldn't invent such a scheme without seriously diverging from SQL compliance: the next naming level up from schemas is reserved for catalogs (think databases). I don't know that we'll ever support cross-database access, but we shouldn't foreclose the possibility in pursuit of a naming scheme that doesn't really add very much value. You could possibly fake it with schema names like org_postgresql_foo, but I can't get very excited about that ... regards, tom lane ---(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] Open 7.3 items
On Sun, Aug 11, 2002 at 11:12:57AM -0400, Tom Lane wrote: Not solved yet. And it's just a matter of time until we run into it with the main parser grammar file as well. Yeah, I've been worrying about that too. Any idea how close we are to trouble in the main grammar? No idea. The ecpg grammar in the main tree has about 530 rules, while my actual version is at nearly 550. The main grammar should be at about 440. So there's some room left. Plan C would be to devote some work to minimizing the number of states in the main grammar (I assume it's number of states that's the problem). I doubt anyone's ever tried, so there might be enough low-hanging fruit to get ecpg off the hook for awhile. Actually I already ate the really low-hanging fruit. :-) I did spend some time to reduce the states, albeit surely not to the extent possible, but still it will mean quite some work I'm afraid. Michael P.S.: No repsonse by bison upstream yet, but I think he's on vacation this week. -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
