Re: ORDER BY with plpgsql parameter - Mailing list pgsql-general

From Thomas Schoen
Subject Re: ORDER BY with plpgsql parameter
Date
Msg-id 200406021733.45550.t.schoen@vitrado.de
Whole thread Raw
In response to Re: ORDER BY with plpgsql parameter  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: ORDER BY with plpgsql parameter  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List 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.


pgsql-general by date:

Previous
From: "Chris Ochs"
Date:
Subject: GRANT question
Next
From: Patrick Hatcher
Date:
Subject: Pg_dump error