At 11:30 AM 3/30/2001 -0600, you wrote:
>In my experience, the best way to find out answers like this is to try it
>out and see. Usually I find that I need to fiddle around with the syntax a
>bit (I believe it's called debugging) before getting something to work.
>Postgresql is very powerful; the capability to utilize that power comes at a
>price. In other words, be prepared to put in a solid investment if you want
>to see a return.
>(I'm not accustomed to preaching, but sometimes this just needs to be said).
Well its good you don't do it often because your not very good at it. ;)
I've spent a reasonable about of time trying different approaches before
posting my question here. If I had the confidence that what I was trying to
do was certainly possible with pl/pgsql - then I'd pursue it until I made
it work. I probably have more tenacity than you realize, despite it being
so very, very obvious by my trying to get an answer in this mailing list.
However, since I could declare a variable called id and have a column in
the table called id and perhaps I want to reference NEW.id where id is the
variable value not the column - then it would seem that whatever parser is
at work may have some ambiguities to cope with. Thus I begin to doubt if
its something that should be expected of pl/pgsql. I've not come across any
way to make a variable reference more explicit to the parser in the
postgres docs.... so I have no choice but to ask here. Then again it would
make good sense if the parser did evaluated variables before evaluating
field references... but the fact is, "I DON'T KNOW".
In response to
pgsql-general by date
|Next:||From: Manuel Sugawara||Date: 2001-03-30 18:21:23|
|Subject: Re: Data access permission?|
|Previous:||From: Jeff Eckermann||Date: 2001-03-30 17:30:14|
|Subject: RE: dynamic field names in a function.|