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