Re: [HACKERS] Almost there on column aliases
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Almost there on column aliases |
Дата | |
Msg-id | 38AC49C8.EF21B38D@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Almost there on column aliases (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Ответы |
Re: [HACKERS] Almost there on column aliases
|
Список | pgsql-hackers |
> >>>> 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: > 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. Ah, right; "bpchar" is "blank padded char". But would there be any downside to removing those blank pads when doing the transformation back to a printed query? i.e. if the outnode() functions stripped the padding? Or maybe at that point there is not enough info to do it? Seems like an ill-advised char(2000) or two in a table might bollux up a lot of potential rules (even more than my extraneous column aliases might ;) - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: