Thread: Re: missing function datetime()
moray.mcconnachie@computing-services.oxford.ac.uk writes: > It looks like replacing all occurrences of datetime with timestamp in > the script works - even for the few functions I have that used the > datetime() function. Oooh --- another case we didn't think about. We really should continue to make a function named datetime() available, even though the type it produces will officially be named timestamp. I can see two ways to do that: either add another function to pg_proc (five of them actually :-(), or hack the parser to translate a function name 'datetime' to 'timestamp'. Ugly as the second one sounds, it has a couple of advantages. First, it would provide an automatic upgrade path: future dumps of 7.0 databases would show the correct function name, at least for uses in rules. So we could hope to get rid of the compatibility hack someday. Second, the parser has special treatment for functions that are named the same as datatypes --- it knows they represent type coercions --- so a function named "datetime" won't really work quite the way it should for type resolution. Not sure which way to jump. Comments anyone? regards, tom lane
> I can see two ways to do that: either add another function to pg_proc > (five of them actually :-(), or hack the parser to translate a function > name 'datetime' to 'timestamp'. Ugly as the second one sounds, it has > a couple of advantages. First, it would provide an automatic upgrade > path: future dumps of 7.0 databases would show the correct function > name, at least for uses in rules. So we could hope to get rid of the > compatibility hack someday. Second, the parser has special treatment > for functions that are named the same as datatypes --- it knows they > represent type coercions --- so a function named "datetime" won't really > work quite the way it should for type resolution. xlateSqlFunc() is already in gram.y; enjoy... - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >> I can see two ways to do that: either add another function to pg_proc >> (five of them actually :-(), or hack the parser to translate a function >> name 'datetime' to 'timestamp'. Ugly as the second one sounds, it has >> a couple of advantages. > xlateSqlFunc() is already in gram.y; enjoy... Will do, just wanted to see if you approved or not. When you finish catching up on the back email, I'd like to know what you think about the question of comment lexing. Should we change scan.l so that it will recognize /* or -- as comment starters even if they are embedded in what would currently be considered a long operator token? If so, is it OK to depend on yyless() to do it, or is that a flex-ism? I'd also kind of like to put in a test to detect unterminated comments and literals. The flex manual recommends <<EOF>> but that only works in flex. I was speculating that a rule for <xq> followed by nothing might work, if all the other <xq> rules match at least one character. Thoughts? regards, tom lane