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 по дате отправления:

Предыдущее
От: Sevo Stille
Дата:
Сообщение: Re: [HACKERS] Definitional issue for INET types
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Definitional issue for INET types