Re: Updated CREATE FUNCTION syntax
От | Joel Burton |
---|---|
Тема | Re: Updated CREATE FUNCTION syntax |
Дата | |
Msg-id | 20020518163406.A98092B811@temp.joelburton.com обсуждение исходный текст |
Ответ на | Re: Updated CREATE FUNCTION syntax (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Updated CREATE FUNCTION syntax
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> said: > Seems like the only way to do that in the backend would be to find a way > of slipping the function text past the lexer/parser entirely. While I > can imagine ways of doing that, I think it'd be a *whole* lot cleaner > to fix things on the client side. > > How do you feel about a psql hack that provides a "function definition" > mode? More generally it could be a mode to enter random text and have > it be converted to an SQL literal string. Perhaps > > psql=> create function foo (int) returns int as > psql-> \beginliteral > psql-LIT> begin > psql-LIT> x := $1; > psql-LIT> ... > psql-LIT> end; > psql-LIT> \endliteral > psql-> language plpgsql; > > Essentially, \beginliteral and \endliteral each convert to a quote > mark, and everywhere in between quotes and backslashes get doubled. > We might want to specify that the leading and trailing newlines get > dropped, too, though for function-definition applications that would > not matter. Tom -- Given that 98% of my function defining is done is psql, this would be fine for me and solve my frustrations. It wouldn'thelp people that build functions in scripting languages or non-psql environments, however, but I don't know how commonthis is. What do others think? Thanks! -- Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton Knowledge Management & Technology Consultant
В списке pgsql-hackers по дате отправления: