Re: [BUGS] Problem identifying constraints which should not be inherited
Hi,
On Fri, Mar 7, 2008 at 6:37 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Added to TODO:
>
> > o Require all CHECK constraints to be inherited
> >
> > http://archives.postgresql.org/pgsql-bugs/2007-04/msg00026.php
>
>
PFA, a small patch attached which should fix this. I have made relevant
changes in the relevant regression files too.
I was wondering though if there are other locations where we might need to
add checks to ensure that ALTER TABLE ONLY parentrel operations are ok? I
did see checks for this in some other operations like ADD COLUMN already in
place too.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/commands/tablecmds.c
===
RCS file: /repositories/postgreshome/cvs/pgsql/src/backend/commands/tablecmds.c,v
retrieving revision 1.242
diff -c -r1.242 tablecmds.c
*** src/backend/commands/tablecmds.c 7 Feb 2008 17:09:51 - 1.242
--- src/backend/commands/tablecmds.c 19 Mar 2008 07:41:32 -
***
*** 229,234
--- 229,236
bool recurse, bool recursing);
static void ATExecAddIndex(AlteredTableInfo *tab, Relation rel,
IndexStmt *stmt, bool is_rebuild);
+ static void ATPrepAddConstraint(List **wqueue, Relation rel, bool recurse,
+ AlterTableCmd *cmd);
static void ATExecAddConstraint(AlteredTableInfo *tab, Relation rel,
Node *newConstraint);
static void ATAddForeignKeyConstraint(AlteredTableInfo *tab, Relation rel,
***
*** 1949,1962
break;
case AT_AddConstraint: /* ADD CONSTRAINT */
ATSimplePermissions(rel, false);
!
! /*
! * Currently we recurse only for CHECK constraints, never for
! * foreign-key constraints. UNIQUE/PKEY constraints won't be seen
! * here.
! */
! if (IsA(cmd->def, Constraint))
! ATSimpleRecursion(wqueue, rel, cmd, recurse);
/* No command-specific prep needed */
pass = AT_PASS_ADD_CONSTR;
break;
--- 1951,1958
break;
case AT_AddConstraint: /* ADD CONSTRAINT */
ATSimplePermissions(rel, false);
! /* Performs own recursion */
! ATPrepAddConstraint(wqueue, rel, recurse, cmd);
/* No command-specific prep needed */
pass = AT_PASS_ADD_CONSTR;
break;
***
*** 3833,3838
--- 3829,3861
}
/*
+ * ALTER TABLE ADD CONSTRAINT
+ *
+ * Currently we recurse only for CHECK constraints, never for
+ * foreign-key constraints. UNIQUE/PKEY constraints won't be seen
+ * here.
+ */
+ static void
+ ATPrepAddConstraint(List **wqueue, Relation rel, bool recurse,
+ AlterTableCmd *cmd)
+ {
+ if (IsA(cmd->def, Constraint))
+ {
+ if (recurse)
+ ATSimpleRecursion(wqueue, rel, cmd, recurse);
+ else
+ /*
+ * If we were told not to recurse, there better not be any
+ * children tables around
+ */
+ if (find_inheritance_children(RelationGetRelid(rel)) != NIL)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
+ errmsg("constraint must be added to children tables too")));
+ }
+ }
+
+ /*
* ALTER TABLE ADD CONSTRAINT
*/
static void
Index: src/test/regress/expected/alter_table.out
===
RCS file: /repositories/postgreshome/cvs/pgsql/src/test/regress/expected/alter_table.out,v
retrieving revision 1.104
diff -c -r1.104 alter_table.out
*** src/test/regress/expected/alter_table.out 29 Oct 2007 21:31:28 - 1.104
--- src/test/regress/expected/alter_table.out 19 Mar 2008 07:41:32 -
***
*** 314,319
--- 314,323
create table atacc1 (test int);
create table atacc2 (test2 int);
create table atacc3 (test3 int) inherits (atacc1, atacc2);
+ -- only add constraint should fail on atacc2
+ alter table only atacc2 add constraint foo check (test2>0);
+ ERROR: constraint must be added to children tables too
+ -- add constraint to parent and children
alter table atacc2 add constraint foo check (test2>0);
-- fail and then succeed on atacc2
insert into atacc2 (test2) values (-3);
***
*** 378,398
NOTICE: drop cascades to table atacc3
NOTICE: drop cascades to constraint foo on table atacc3
drop table atacc1;
- -- let's try only to add only to the parent
- create table atacc1 (test int);
- create table atacc2 (test2 int);
- create table atacc3 (test3 int) inherits (atacc1, atacc2);
- alter table only atacc2 add constraint foo check (test2>0);
- -- fail and then succeed on atacc2
- insert into atacc2 (test2) values (-3);
- ERROR: new row for relation "atacc2" violates check constraint "foo"
- insert into atacc2 (test2) values (3);
- -- both succeed on atacc3
- insert into atacc3 (test2) values (-3);
- insert into atacc3 (test2) values (3);
- drop table atacc3;
- drop table atacc2;
- drop table atacc1;
-- test unique constraint adding
create table atacc1 ( test int ) with oids;
-- add a unique constraint
--- 382,387
Index: src/te
[BUGS] BUG #4046: Error on connection
The following bug has been logged online: Bug reference: 4046 Logged by: kusum Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows XP professional Description:Error on connection Details: When we try to connect to postgresql it gives an error Failed to connect to port 5432. on localhost.It says does the ip 127.0.0.1 accept connections on port 5432. So it does not allow us to connect to the database. And this error occurs every third or fourth day and we have to reintall the s/w and then again after a few days we get that error and we are not able to connect to the local server. -- 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] 8.3 can't convert cyrillic text from 'iso-8859-5' to other cyrillic 8-bit encoding
Sergey Burladyan wrote: src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c does not have cyrillic letter 'IO' in ISO-8859-5 to mule internal code translation table (function iso2mic(const unsigned char *l, unsigned char *p, int len)). this is bug, because it is widely used and it is main letter like A, B or C in english :) and it is exist in all russian cyrillic's encoding (koi8-r, iso-8859-5, windows-1251, cp866). for example, in russian, words 'all', 'hedgehog', 'Christmas-tree' and many other must be written with it. here is the patch for add it to ISO-8859-5 to mule internal code translation table. i am don't know is this ok and do not brake any internal rule or code ? You'd need to modify the mic->ISO-8859-5 translation table as well, for converting in the other direction. By the way, as i can understand you are using koi8-r encoding for internal representation of cyrillic charsets - this is have also another problem. the second "widely" used char is NUMERO SIGN (many accountants and managers use it :) in cyrillic windows world) and it is exist in windows-1251, cp866 and iso-8859-5 encoding, but not in koi8-r... 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. Is there any other characters like "YO" that are missing, that exist in all the encodings? Looking at the character set table for KOI8-R, it looks like the "YO" is in an odd place in the table, compared to all other cyrillic characters. Perhaps that's why it was missed. -- 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: >> Description:Incorrect RegExp substring Output > >>SUBSTRING( BedNo FROM '^[[:digit:]]+[a-zA-Z]*(:[[:digit:]]+)?$' ) > > Interesting. It had never occurred to me that it's possible for the > whole pattern to have a match when some parenthesized subexpression > has no match. On investigation, Tcl's regex library seems to get > this right, but textregexsubstr() doesn't. Will fix. > >> I would expect the result for BedNumber to be either NULL or the EMPTY >> String, and the later seems more logical. > > It's going to be null. Your example has no match to the parenthesized > substring --- a match would have to include a colon and some digits, no? Yes, the subexpression will not match, but the entire expression will. Taking this into account I agree that it should be NULL then, but this should be CLEARLY stated in the MANUAL, so that the user will not have to guess. I believe that there should be a more detailed explanation of Substring function in the manual, because I haven't found a specific section about it. It is kind of scattered around the string functions page. > regards, tom lane Thank you for your feedback. P.S. Will the fix be available as a patch or just in 8.3.1 ? See ya 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] BUG #4044: Incorrect RegExp substring Output
"Rui Martins" <[EMAIL PROTECTED]> writes: > Here the context of the word "match" may be misleading us, in this > conversation. > I say this, because in my report, the second substring expression, the one > for RoomSize: > SUBSTRING( BedNo, '^[[:digit:]]+([a-zA-Z]*)(:[[:digit:]]+)?$' ) AS RoomSize, > Actually returns an EMPTY String, and not a NULL, for the first 2 test > cases, which I believe is the correct answer. What's your point? A zero-length substring is a legal match to that subexpression ... unlike the third one. 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
NikhilS <[EMAIL PROTECTED]> writes: > On Fri, Mar 7, 2008 at 6:37 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: >> Added to TODO: >> o Require all CHECK constraints to be inherited > PFA, a small patch attached which should fix this. 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. 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 Just a side note, See comments below. > "Rui Martins" <[EMAIL PROTECTED]> writes: >> Description:Incorrect RegExp substring Output > >>SUBSTRING( BedNo FROM '^[[:digit:]]+[a-zA-Z]*(:[[:digit:]]+)?$' ) > > Interesting. It had never occurred to me that it's possible for the > whole pattern to have a match when some parenthesized subexpression > has no match. On investigation, Tcl's regex library seems to get > this right, but textregexsubstr() doesn't. Will fix. > >> I would expect the result for BedNumber to be either NULL or the EMPTY >> String, and the later seems more logical. > > It's going to be null. Your example has no match to the parenthesized > substring --- a match would have to include a colon and some digits, no? You mention that it will return NULL, when the subexpression does not match! Here the context of the word "match" may be misleading us, in this conversation. I say this, because in my report, the second substring expression, the one for RoomSize: SUBSTRING( BedNo, '^[[:digit:]]+([a-zA-Z]*)(:[[:digit:]]+)?$' ) AS RoomSize, Actually returns an EMPTY String, and not a NULL, for the first 2 test cases, which I believe is the correct answer. >From what I can infer, from your definition, of "match", from your last sentence, this should NOT be a MATCH for the Subexpression, since it would be an EMPTY match. However, it's returning EMPTY String instead of NULL. i.e. returns what I expect and not what you have said it should return in case of NO MATCH. I usually think that a "match" is something that validates as correct, and hence returns something. But I have to admit that I usually think about a global match, i.e. the entire expression match, and not about sub-expression match. 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. My expectations and assumptions might be wrong, but I believe they are correct. Please check this too. Once again, thank you for your quick 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
Re: [BUGS] BUG #4044: Incorrect RegExp substring Output
Hi Tom What I meant is: SELECT '' ~ '^(something)?$' This will match, i.e. the empty string will match with the expression, and substring would return and empty string. or in other words: it returns true SELECT SUBSTRING( '', '^(something)?$' ) This will also match, has a global expression, and the return is, has expected, an EMPTY string ! Now, If all the above is correct (which I believe it is), than: SELECT 'TEST' ~ '^TEST(something)?$' Will also return TRUE, which it correctly does. So, what would you expect to be the result, from the following query ? SELECT SUBSTRING( 'TEST', '^TEST(something)?$' ) The current returned value is 'TEST' which is wrong! This we knew already, from my bug Report. But by analogy, with the previous queries, and to maintain overall coherence the expected correct result should be and EMPTY string too! But If I understood you correctly, you said that it will return a result of NULL, which I think is incorrect. Did I make my self clearer know ? Thanks again for feedback. See ya Rui Martins > "Rui Martins" <[EMAIL PROTECTED]> writes: >> Here the context of the word "match" may be misleading us, in this >> conversation. >> I say this, because in my report, the second substring expression, the >> one >> for RoomSize: > >> SUBSTRING( BedNo, '^[[:digit:]]+([a-zA-Z]*)(:[[:digit:]]+)?$' ) AS >> RoomSize, > >> Actually returns an EMPTY String, and not a NULL, for the first 2 test >> cases, which I believe is the correct answer. > > What's your point? A zero-length substring is a legal match to that > subexpression ... unlike the third one. > > 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: > 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 -- 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] 8.3 can't convert cyrillic text from 'iso-8859-5' to other cyrillic 8-bit encoding
Heikki Linnakangas wrote: Sergey Burladyan wrote: src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c does not have cyrillic letter 'IO' in ISO-8859-5 to mule internal code translation table (function iso2mic(const unsigned char *l, unsigned char *p, int len)). this is bug, because it is widely used and it is main letter like A, B or C in english :) and it is exist in all russian cyrillic's encoding (koi8-r, iso-8859-5, windows-1251, cp866). for example, in russian, words 'all', 'hedgehog', 'Christmas-tree' and many other must be written with it. here is the patch for add it to ISO-8859-5 to mule internal code translation table. i am don't know is this ok and do not brake any internal rule or code ? You'd need to modify the mic->ISO-8859-5 translation table as well, for converting in the other direction. 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. By the way, as i can understand you are using koi8-r encoding for internal representation of cyrillic charsets - this is have also another problem. the second "widely" used char is NUMERO SIGN (many accountants and managers use it :) in cyrillic windows world) and it is exist in windows-1251, cp866 and iso-8859-5 encoding, but not in koi8-r... 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. Is there any other characters like "YO" that are missing, that exist in all the encodings? Looking at the character set table for KOI8-R, it looks like the "YO" is in an odd place in the table, compared to all other cyrillic characters. Perhaps that's why it was missed. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com Index: src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c,v retrieving revision 1.16 diff -c -r1.16 cyrillic_and_mic.c *** src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c 1 Jan 2008 19:45:53 - 1.16 --- src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c 19 Mar 2008 21:04:40 - *** *** 483,489 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe1, 0xe2, 0xf7, 0xe7, 0xe4, 0xe5, 0xf6, 0xfa, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 0xf0, --- 483,489 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! 0x00, 0xb3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe1, 0xe2, 0xf7, 0xe7, 0xe4, 0xe5, 0xf6, 0xfa, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 0xf0, *** *** 493,499 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd2, 0xd3, 0xd4, 0xd5, 0xc6, 0xc8, 0xc3, 0xde, 0xdb, 0xdd, 0xdf, 0xd9, 0xd8, 0xdc, 0xc0, 0xd1, ! 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; --- 493,499 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd2, 0xd3, 0xd4, 0xd5, 0xc6, 0xc8, 0xc3, 0xde, 0xdb, 0xdd, 0xdf, 0xd9, 0xd8, 0xdc, 0xc0, 0xd1, ! 0x00, 0xa3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; *** *** 509,517 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xee, 0xd0, 0xd1, 0xe6, 0xd4, 0xd5, 0xe4, 0xd3, 0xe5, 0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, --- 509,517 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0xf1, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! 0x00, 0x00, 0x00, 0xa1, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xee, 0xd0, 0xd1, 0xe6, 0xd4, 0xd5,
Re: [BUGS] 8.3 can't convert cyrillic text from 'iso-8859-5' to other cyrillic 8-bit encoding
Thursday 20 March 2008 01:16:34 Heikki Linnakangas:
Thanks for answer, Heikki !
> You'd need to modify the mic->ISO-8859-5 translation table as well, for
> converting in the other direction.
oops, i have not thought about it %)
> 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 :)
create or replace function test_convert() returns setof record as $$
declare
--- russian alphabet, 33 upper and 33 lower letters in utf-8 encoding
r bytea default
E'\320\260\320\261\320\262\320\263\320\264\320\265\321\221\320\266\320\267\320\270\320\271\320\272\320\273\320\274\320\275\320\276\320\277\321\200\321\201\321\202\321\203\321\204\321\205\321\206\321\207\321\210\321\211\321\212\321\213\321\214\321\215\321\216\321\217\320\220\320\221\320\222\320\223\320\224\320\225\320\201\320\226\320\227\320\230\320\231\320\232\320\233\320\234\320\235\320\236\320\237\320\240\320\241\320\242\320\243\320\244\320\245\320\246\320\247\320\250\320\251\320\252\320\253\320\254\320\255\320\256\320\257';
s bytea; --- converted to result
t bytea; --- converted back result
res record;
begin
raise notice 'russian ABC: "%"', encode(r, 'escape');
s := convert(r, 'utf-8', 'iso-8859-5');
t := convert(s, 'iso-8859-5', 'windows-1251'); t :=
convert(t, 'windows-1251', 'utf-8');
if t != r then
raise exception 'iso-8859-5, windows-1251 | t != r';
end if;
res := row('iso-8859-5, windows-1251'::text, encode(
convert(convert(s, 'iso-8859-5', 'windows-1251'), 'windows-1251', 'utf-8')
, 'escape')::text
);
return next res;
[...skip...]
seb=# select * from test_convert() as (conv text, res text);
NOTICE: russian ABC: "абвгдеёжз..."
conv|res
+---
iso-8859-5, windows-1251 | абвгдеёжз...
iso-8859-5, windows-866| абвгдеёжз...
iso-8859-5, koi8-r | абвгдеёжз...
iso-8859-5, iso-8859-5 | абвгдеёжз...
windows-866, windows-1251 | абвгдеёжз...
windows-866, iso-8859-5| абвгдеёжз...
windows-866, koi8-r| абвгдеёжз...
windows-866, windows-866 | абвгдеёжз...
windows-1251, windows-866 | абвгдеёжз...
windows-1251, iso-8859-5 | абвгдеёжз...
windows-1251, koi8-r | абвгдеёжз...
windows-1251, windows-1251 | абвгдеёжз...
koi8-r, windows-866| абвгдеёжз...
koi8-r, iso-8859-5 | абвгдеёжз...
koi8-r, windows-1251 | абвгдеёжз...
koi8-r, koi8-r | абвгдеёжз...
(16 rows)
> 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 %)
> 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...
> Looking at the character set table for KOI8-R, it
> looks like the "YO" is in an odd place in the table, compared to all
> other cyrillic characters. Perhaps that's why it was missed.
Yes, i understand. russian character sets always been a challenge for all
programmers :) it are at least five, and it are all different
Thanks for patch, Heikki !
---
--
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 Wed, Mar 19, 2008 at 8:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > NikhilS <[EMAIL PROTECTED]> writes: > > On Fri, Mar 7, 2008 at 6:37 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > >> Added to TODO: > >> o Require all CHECK constraints to be inherited > > > PFA, a small patch attached which should fix this. > > 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. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
