Re: ORDER BY with plpgsql parameter

From: Thomas Schoen <t(dot)schoen(at)vitrado(dot)de>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: ORDER BY with plpgsql parameter
Date: 2004-06-02 15:33:45
Message-ID: 200406021733.45550.t.schoen@vitrado.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On Wed, 2 Jun 2004, Thomas Schoen wrote:
> > > You need to use the FOR-IN-EXECUTE style of query. That way
> > > you can use any string you want (including text passed in as
> > > a parameter) to build the query inside the function ...
> >
> > that is what i want to avoid. (i wrote that in my first mail)
> > My question was about why it is not possible to do it like this:
> > ....ORDER BY $1
>
> One problem is that doing the above as column name would make the $1 have
> a different meaning from its use in other places like where clauses (where
> it acts like a bound parameter).

I know what you mean.
I'm aware of this problem. I tired to quote the parameter using quote_ident
functions which did not work either.
I do not unserstand the logic behind parameters used in plpgsql-functions.
I don't know how they are bound inside the database-logic.

>
> Apart from the quoting issue, I'm also not sure how it would be any
> different from for-in-execute in any case.
Maybe thats just my preference.
I don't like the "build a string to interpret" kind of code.
But it would be interesting to know if their are any performance disadvantages
when using the "for in execute".
My experience of using "for in execute" was so far that it is much slower than
doing it the direct way - and way slower than using sql-functions instead of
plpgsql-functions.
Maybe that experience was subjective.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alexander Cohen 2004-06-02 15:50:33 interactive backend output
Previous Message Mark Harrison 2004-06-02 15:22:14 Re: async problems?