Re: [INTERFACES] Re: [HACKERS] changes in 6.4
От | Thomas G. Lockhart |
---|---|
Тема | Re: [INTERFACES] Re: [HACKERS] changes in 6.4 |
Дата | |
Msg-id | 35AE01C1.DFC343BA@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] atttypmod now 32 bits, interface change] (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
> > TRIM is keyword, not a function... > > We have to copy some lines in gram.y > Wow! is this standard ? > I found the function trim by doing 'select oprname from pg_oper' > and tested it as follows: > > hannu=> select trim(' x '); > btrim > ----- > x > (1 row) > why is the column called btrim ? > some rewrite magic in parser ? > If it must stay a keyword, then perhaps we should remove the proc ? Uh, yes, I think you are right. Here's why: The SQL92 syntax for the trim() function is as follows: TRIM([LEADING|TRAILING|BOTH] [char FROM] string) This syntax is _not_ the clean "function(arg1,arg2,...)" syntax that the parser could handle without change, so I had to make TRIM a keyword in the parser and explicitly decode the possible argument phrases. To implement all possibilities, I transform the function in the parser to the functions btrim(), rtrim(), and ltrim() implemented earlier by Edmund Mergl as the "Oracle compatibility functions". I'll add TRIM() and the other goofy pseudo-functions to the CHECK syntax, and take the trim(arg1) declaration out of pg_proc since it can never get executed. Oh, btw we allow trimming strings from strings, not just trimming chars from strings :) - Tom
В списке pgsql-hackers по дате отправления: