On Feb 3, 2006, at 02:09, Tino Wildenhain wrote:
Well if the view does not suit your needs, why dont you use an
set returnung function instead? Inside it you can do all the magic
you want and still use it similar to a table or view.
That's what I'm currently doing (as explained in the first
On Fri, Feb 03, 2006 at 08:33:23AM -0500, Chris Campbell wrote:
On Feb 3, 2006, at 02:09, Tino Wildenhain wrote:
Well if the view does not suit your needs, why dont you use an
set returnung function instead? Inside it you can do all the magic
you want and still use it similar to a table or
On Feb 3, 2006, at 08:50, Martijn van Oosterhout wrote:
Hmm, we actually do inline SQL functions under certain situations, but
only for simple queries (see inline_function in
optimizer/util/clauses.c). One approach would be to expand that
function to inline more complicated things.
* Better
On Fri, Feb 03, 2006 at 09:18:51AM -0500, Chris Campbell wrote:
So you think approaching it from the beefing up functions side
would be better than the beefing up views side?
Well yes, I think you're underestimating the issues with trying to
extend views.
Technically a bug. We should be
On Feb 3, 2006, at 10:25, Martijn van Oosterhout wrote:
Sure, for most procedural languages you can't do much. But we do do
syntax checking already and checking that the necessary functions
exist
can be considered part of that. It' s not terribly important though.
Dependancy tracking needs
Chris Campbell [EMAIL PROTECTED] writes:
I want to beef up rules versus beefing up functions.
Martijn didn't present a very convincing argument why this is a bad
idea, but I agree with him that it is. The problem to me is that a
view with arguments is fundamentally wrong --- a view is a virtual
Chris Campbell [EMAIL PROTECTED] writes:
True, as long as there's a hook to do the inlining/rewriting before
the query's planned. I guess we can see function calls at the parse
stage, check to see if they're SQL functions or not, grab the prosrc,
do the substitution, then re-parse?
On Feb 3, 2006, at 12:27, Tom Lane wrote:
I guess I can live without the dependancy tracking. I can always dump
and reload my database to re-parse all the functions. Maybe we could
have a RELOAD FUNCTION command that would just re-parse an existing
function, so I don't have to dump and reload?
Chris Campbell [EMAIL PROTECTED] writes:
I'm fine with those limitations. I can confirm that all of my
functions are not referencing tables that don't exist by doing a
CREATE OR REPLACE FUNCTION to reload each function. A pg_dump/
pg_restore would accomplish this, but it would be nice to
Tom,
As for the dependency issue, one man's bug is another man's feature.
I think the fact that we don't track the internal dependencies of
functions is not all bad. We've certainly seen plenty of complaints
about how you can't easily change tables that a view is depending on
because the
Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
True, as long as there's a hook to do the inlining/rewriting before
the query's planned. I guess we can see function calls at the parse
stage, check to see if they're SQL functions or not, grab the prosrc,
do the substitution, then
Josh Berkus josh@agliodbs.com writes:
BTW, the other thing that we're still TODOing on SRFs (as far as I know) is
finding ways to change the row estimate for an SRF. It's still a flat
1000 in the code, which can cause a lot of bad query plans. I proposed a
year ago that, as a first step,
Mark Dilger [EMAIL PROTECTED] writes:
If we are talking about inserting the function definition into the
query as a subquery and then letting the parser treat it as a
subquery, then I see no reason to use either the existing function or
view subsystems. It sounds more like we are discussing a
Josh Berkus wrote:
Tom,
As for the dependency issue, one man's bug is another man's feature.
I think the fact that we don't track the internal dependencies of
functions is not all bad. We've certainly seen plenty of complaints
about how you can't easily change tables that a view is depending
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
If we are talking about inserting the function definition into the
query as a subquery and then letting the parser treat it as a
subquery, then I see no reason to use either the existing function or
view subsystems. It sounds more like we
On Feb 3, 2006, at 11:21, Tom Lane wrote:
The SRF concept captures what you want a whole lot better. If the
implementation isn't up to snuff, we should improve it, not warp other
pieces of the system.
Point taken. The rewriting concept is what I'm after; if that can be
done pre-planning
I've written some complicated queries that I'd like to save inside
the server and then call from my clients using a short name. For the
queries that require no external information, views are perfect. For
queries that *do* require external information (like a search date
range), I've used
Chris Campbell [EMAIL PROTECTED] writes:
What do you think? Is this an interesting feature? Is this the right way to
go
about it, or should I try to get the planner to see through SQL function
boundaries
The right way to go about this in the original abstract set-theoretic
mindset of SQL
On Feb 2, 2006, at 23:33, Greg Stark wrote:
The right way to go about this in the original abstract set-
theoretic
mindset of SQL is to code the view to retrieve all the rows and
then apply
further WHERE clause restrictions to the results of the view.
So for example this:
CREATE VIEW
Chris Campbell schrieb:
...
That was a very simplistic example and didn't illustrate my point -- I
apologize. I was trying to think of something succinct and illustrative
for a quick mailing list post but came up short.
Maybe a better example would be a situation where you want to do
20 matches
Mail list logo
