Thread: 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 N I 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_dumpsfix up function return types on lang/type/trigger creation or loosen opaque restrictionsfunctions
nolonger public executablelanguages no longer public usable
Add schema dump option to pg_dump
Add casts: (Tom)assignment-level cast specificationinet -> textmacaddr -> textint4 -> varchar?int8 -> varchar?add param
forlength 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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
> 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
> 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
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 peter_e@gmx.net
Peter Eisentraut wrote: > 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. > Added to open items: Fix SIMILAR TO to be Posix compiant or remove it I still had your email in my mailbox so I wouldn't have forgotten. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 ...
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 ...
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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? :)
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*)
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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?
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?
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Marc G. Fournier" <scrappy@hub.org> 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
"Marc G. Fournier" <scrappy@hub.org> 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 <neilc@samurai.com> || PGP Key ID: DB3C29FC
> 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
Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) --------------------------------------------------------------------------- Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Marc G. Fournier" <scrappy@hub.org> 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
Tom Lane wrote:
> "Marc G. Fournier" <scrappy@hub.org> 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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
On Wed, 18 Sep 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> 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 ...
On Wed, 18 Sep 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> 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. What would it take to get it to a fixed state? Who implemented SIMILAR TO in the first place? Who is able to fix this? And, finally, what are the implications of leaving things as they are? From my read of what you are saying above, its currently implemented with an implied ^ and $ around the pattern match?
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" <scrappy@hub.org> 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 > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 >
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" <scrappy@hub.org> 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 > > pgman@candle.pha.pa.us | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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" <scrappy@hub.org> 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 > > > pgman@candle.pha.pa.us | (610) 359-1001 > > > + If your life is a hard drive, | 13 Roberts Road > > > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > > > > > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 >
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 ...
Bruce Momjian <pgman@candle.pha.pa.us> 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
"Marc G. Fournier" <scrappy@hub.org> 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
"Marc G. Fournier" <scrappy@hub.org> 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
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Thu, 19 Sep 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> 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... 'K, just curious here, but ... Thomas, do you agree with Tom's interpretation of the spec? If so, would it be possible to get the above fixed? Or is there an ambiguity there (not like *that* has never happened before) that Tom/Peter are being more strict about then the spec requires?
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 peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> 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
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Peter Eisentraut <peter_e@gmx.net> 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
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" <scrappy@hub.org> 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 majordomo@postgresql.org) > Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com ==========================================================================
> On Thu, 19 Sep 2002, 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.
I did something about this. The translation function probably needs
work (for one thing, it's not multibyte-aware) but it's a start; and
we shouldn't need any more initdbs to tweak it.
regards, tom lane
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" <scrappy@hub.org> 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 > >