Re: [HACKERS] Table functions and AS clauses ...

[Joe Conway]

Hans-Jürgen Schönig wrote:
However, my question is: Is there a way to implement it in a way that 
does not depend on the remote data structure?
Is there a way to get rid of the AS without having to define a type?
Unfortunately, no. The parse and planning stages need defined types, so 
waiting for the function to execute is too late. We've discussed it a 
time or two before (as recently as within the last week), but the 
conclusion has been that there is no easy answer to the problem.

Joe



---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

[HACKERS] Table functions and AS clauses ...

[Hans-Jürgen Schönig]

Currently I am able to do ...

SELECT dblink_oraconnect('scott/[EMAIL PROTECTED]');
SELECT * FROM dblink_ora('SELECT ename, sal FROM emp')
AS (ename text, sal text);
The problem is: If I wanted to do a

SELECT * FROM dblink_ora('SELECT * FROM emp');

It won't work because dblink_ora returns SETOF RECORD. If could define a 
type representing the remote data structure.
However, my question is: Is there a way to implement it in a way that 
does not depend on the remote data structure?
Is there a way to get rid of the AS without having to define a type?

Maybe somebody can provide me some information about that or point to me 
to some material about this topic.

If we had a solution for that, we could go ahead and do some basic OLAP 
operations. Imagine we had a cube generated by the means of SQL.

We could do

SELECT * FROM some_olap_operation(cube, ...);

without worrying about the elements in a certain dimension which should 
be displayed in the x-axis (as columns).
If there was a nice workaround or a solution I'd be really happy :).

	Regards,

		Hans

--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706; +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at


---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org