Re: [HACKERS] Almost there on column aliases
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Almost there on column aliases |
Дата | |
Msg-id | 15936.950804668@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Almost there on column aliases (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >>>> I'm currently (2000-02-16 15:40 GMT) seeing the rules test >>>> blank-filling the "bpchar" fields. Do you see that? > Hmm. Still seeing it; here is a snippet from a diff of > results/rules.out and expected/rules.out: > ... > < rtest_emp | rtest_emp_ins | CREATE RULE rtest_emp_ins > AS ON INSERT TO rtest_emp DO > INSERT INTO rtest_emplog (ename, who, "action", newsal, oldsal) > VALUES (new.ename, getpgusername(), > 'hired '::bpchar, new.salary, '$0.00'::money); > ... >> rtest_emp | rtest_emp_ins | CREATE RULE rtest_emp_ins > AS ON INSERT TO rtest_emp DO > INSERT INTO rtest_emplog (ename, who, "action", newsal, oldsal) > VALUES (new.ename, getpgusername(), > 'hired'::bpchar, new.salary, '$0.00'::money); > ... Oh, I'm sorry, I *am* seeing that. I don't think this has anything to do with your changes; the system's been producing pre-padded strings in those tests for a while now, at least on good days ;-). If you look closely you'll see that the padded string has just been pre-coerced to the length of the char() target field. I don't think that's wrong. The difference is normally masked from causing a comparison failure in the regress tests because we use diff -w to look for differences. Probably the expected file was last updated at a time when it wasn't doing that... regards, tom lane
В списке pgsql-hackers по дате отправления: