Re: Schemas not available for pl/pgsql %TYPE....
От | Sean Chittenden |
---|---|
Тема | Re: Schemas not available for pl/pgsql %TYPE.... |
Дата | |
Msg-id | 20020905200700.GE59269@ninja1.internal обсуждение исходный текст |
Ответ на | Re: Schemas not available for pl/pgsql %TYPE.... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
> > ::sigh:: Is it me or does it look like all > > of pl/pgsql is schema un-aware (ie, all of the declarations). -sc > > Yeah. The group of routines parse_word, parse_dblword, etc that are > called by the lexer certainly all need work. There are some > definitional issues to think about, too --- plpgsql presently relies > on the number of names to give it some idea of what to look for, and > those rules are probably all toast now. Please come up with a > sketch of what you think the behavior should be before you start > hacking code. Not a problem there. I walked around the code for a bit, made a few hacks to see how things are working, and I can tell you strait up that if you'd like this by 7.3, it won't be happening from me. <:~) I'm stretched kinda thin as is and don't think I'll be able to get this working correctly with time to test by release. I can send you the patch I've got for the lexer, but that was chump. What I was going to do could be totally wrong, but... * Change the lexer to recognize schema.table.column%TYPE as a token and was going to create parse_tripwordtype() that'd look up the table and column in the appropriate schema and would return the appropriate type. If I were lazy, I'd just unshift the schema off of the token and return what comes back from parse_dblwordtype(), but that doesn't strike me as correct for something that's performance sensitive. Beyond doing that, I'm at a loss. :-/ Thoughts? -sc -- Sean Chittenden
В списке pgsql-bugs по дате отправления: