Re: [BUGS] 8.3 can't convert cyrillic text from 'iso-8859-5' to other cyrillic 8-bit encoding
Sergey Burladyan wrote: Thursday 20 March 2008 01:16:34 Heikki Linnakangas: Here's a patch that does the conversion in the other direction as well. As I'm not too familiar with cyrillic, can you double-check that this works? I tested it using the convert() function between different encodings, and it seems ok to me. yes, i test it with function like this and it work now :) Ok, patch applied. Hmm. We use KOI8-R (or rather, MULE_INTERNAL with KOI8-R ) as an intermediate encoding, because there's no direct conversion table between ISO-8859-5 and the other cyrillic encodings. Ideally there would be. Another possibility would be to use UTF-8 as the intermediate encoding; that'd probably be much slower, but UTF-8 should have all the characters needed. I think that UTF-8 is too complex for translate 8-bit charset to another 8-bit charset, but other solution is many many translate tables... hard question %) Yeah. It's probably not worth the effort to change/test it. Apparently there's not many people using these conversion functions, as the bug has been there since 7.3 and you're the first one to notice. Is there any other characters like "YO" that are missing, that exist in all the encodings? if we say about alphabet letters, the answer is - No, only "YO" was missing. if we say about any character, there is 'NO-BREAK SPACE' (U+00A0) it exist in 1251, 866, koi8-r and iso but i do not think that it widely used... Ok, good. Thanks for the report and the patch! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4044: Incorrect RegExp substring Output
> "Rui Martins" <[EMAIL PROTECTED]> writes: >> Even though this can me though as argumentative, think about this >> expression: > >> (something)? > >> Will "match" with an empty string in the context of a full expression, >> and >> will return an EMPTY String. So by analogy, I would expect it, to return >> the same as a sub-expression when it actually has a "match" even if with >> an empty sub-string. > > Uh, no, it *won't* match if there is not "something" in the string. > > The behavior you are looking for is properly obtained this way: > > ((something)?) > > This will return either "something" or an empty string (assuming > we have a globally successful match). The point is there's a difference > between what X matches (or doesn't) and what X? matches. > > regards, tom lane OK, what I'm trying to explain is maybe a difference of assumptions: SELECT '' ~ '^(something)?$' NOW: True ME: True YOU: True SELECT SUBSTRING( '', '^(something)?$' ) NOW: '' => EMPTY String (OK, by pure luck. It's returning FULL match) ME: '' => EMPTY String YOU: NULL SELECT 'TEST' ~ '^TEST(something)?$' NOW: True ME: True YOU: True SELECT SUBSTRING( 'TEST', '^TEST(something)?$' ) NOW: 'TEST' => WRONG !!! (It's returning FULL Match) ME: '' => EMPTY String YOU: NULL My reasoning is: Why would the exact same sub-expression, return different results when either preceded or followed by something. In my opinion, the same sub-expression should always return the same result if the same conditions are met (in the sub-expression context). Hope this time it's clear. Best Regards Rui Martins -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problem identifying constraints which should not be inherited
NikhilS escribió: > On Wed, Mar 19, 2008 at 8:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > If it's a small patch, it's wrong by definition. AFAICS there is no way > > to fix this correctly that doesn't involve catalog changes. The point > > of the TODO is that you have to enforce that the inherited constraint > > sticks around, eg can't be dropped on a child table while it's still > > present on the parent. There are implications for pg_dump too. > > Ok, I understand. But even then this could patch could be considered even if > it does not solve the TODO completely, no? It atleast disallows ONLY ADD > CONSTRAINT on the parent. No, because you would then feel that the TODO item is completed and not provide a patch for the whole problem :-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problem identifying constraints which should not be inherited
Hi, On Thu, Mar 20, 2008 at 6:11 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > NikhilS escribió: > > > On Wed, Mar 19, 2008 at 8:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > > > If it's a small patch, it's wrong by definition. AFAICS there is no > way > > > to fix this correctly that doesn't involve catalog changes. The point > > > of the TODO is that you have to enforce that the inherited constraint > > > sticks around, eg can't be dropped on a child table while it's still > > > present on the parent. There are implications for pg_dump too. > > > > Ok, I understand. But even then this could patch could be considered > even if > > it does not solve the TODO completely, no? It atleast disallows ONLY ADD > > CONSTRAINT on the parent. > > No, because you would then feel that the TODO item is completed and not > provide a patch for the whole problem :-) > :) Guess, I should have been wordier in my earlier response and should have mentioned: "This patch, if acceptable can be considered as a small step towards the TODO" too. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
Re: [BUGS] BUG #4044: Incorrect RegExp substring Output
"Rui Martins" <[EMAIL PROTECTED]> writes: > My reasoning is: > Why would the exact same sub-expression, return different results when > either preceded or followed by something. It *isn't* returning different results; you are testing for different things in these two cases, namely whether there is a match to the whole pattern or just a parenthesized subpattern. In none of these examples was there any match to '(something)' --- there couldn't possibly be, because "something" isn't in the data string. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problem identifying constraints which should not be inherited
Alvaro Herrera <[EMAIL PROTECTED]> writes: > NikhilS escribió: >> Ok, I understand. But even then this could patch could be considered even if >> it does not solve the TODO completely, no? It atleast disallows ONLY ADD >> CONSTRAINT on the parent. > No, because you would then feel that the TODO item is completed and not > provide a patch for the whole problem :-) More to the point, it takes a capability away from the user without actually solving the problem we need to solve, namely to guarantee consistency between parent and child constraints. You can be sure that there is someone out there who will complain that we've broken his application when we disallow this, and we need to be able to point to some positive benefit we got from it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4044: Incorrect RegExp substring Output
"Rui Martins" <[EMAIL PROTECTED]> writes: > But the sub-expression did "match" ! No, the sub-expression "(something)" did not match. What did match is the larger expression "(something)?". You seem to be failing to recognize that these are two different things. If you put the capturing parentheses around the larger expression then you will get the result you want. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4044: Incorrect RegExp substring Output
Hi Tom > "Rui Martins" <[EMAIL PROTECTED]> writes: >> My reasoning is: >> Why would the exact same sub-expression, return different results when >> either preceded or followed by something. > > It *isn't* returning different results; you are testing for different > things in these two cases, namely whether there is a match to the whole > pattern or just a parenthesized subpattern. In none of these examples > was there any match to '(something)' --- there couldn't possibly be, > because "something" isn't in the data string. > > regards, tom lane That's one way to look at it. That's why I mentioned the possibility of different assumptions regarding the context of the word "match". In fact, you are saying that the sub-expression did not "match" because there wasn't "something" in the string to be matched! I agree with you on this last part, "there wasn't "something" in the string to be matched" But the sub-expression did "match" ! I say this, because, since the empty string is a valid "match" for "(something)?" because the "?" question mark operator, is defined as "a sequence of 0 or 1 matches of the atom". So we are probably just discussing semantics here! My concern is that many will make the same refutable "valid" assumptions that I do. And If they will get NULL instead of an EMPTY String, it will be awkward, besides not being able to distinguish between an EMPTY "match" and NO "match" at all, since both will return NULL, according to your definition. But what I find odd, is that you say that I'm testing different things. So what would you say for the following cases ? '(something)?' NOTE: I removed the anchors only. Now is this a full string match or a sub-expression match ? We can't give a concrete answer, unless we know the concrete string to be matched SELECT '' ~ '(something)?' This will be a FULL match SELECT 'TEST' ~ '(something)?' But this one won't! It will be a sub-expression match by your definition. So using the EXACT same REG_EXP, we will have two different context, depending on the input ! The regexp context, MUST NOT depend on the String to be matched. Because if it depends, then this is VERY BAD for consistency. Do you get my point now ? Now try this: SELECT SUBSTRING( '', '(something)?' ) SELECT SUBSTRING( 'TEST', '(something)?' ) Odd enough, this, currently, returns the correct answer for both queries! And by correct I mean EMPTY String ! According to your assumption, the first, would return an Empty String, but the second, would return NULL ! You should try this with other reg_exp implementations, and see what comes up on the the sub-expression result. If after this exposition I haven't been able to correctly transmit the problem to you, then it's probably my inability to explain it better, or my not so good English, since it's not my native language. Hope you understand this now, since I don't know how to explain it better. Thank you for your feedback. Best Regards Rui Martins -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
