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 wit
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
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
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 discuss
Josh Berkus 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, we allow the f
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
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 th
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 nic
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:
> 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?
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 vir
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
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
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 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 tab
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 me
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
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 <[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
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 f
20 matches
Mail list logo
