Hello
I would to use EXECUTE USING for optimalisation query
SELECT * FROM tab WHERE column = param OR param IS NULL
(if param isn't null then use param else ignore this params)
Planner can do it:
postgres=# explain select * from test where a = 100 or 100 is null;
Q
I think the real problem here is that PostgreSQL is very finicky about
what operations you can perform on a view. If I have a table foo and
I define a view bar that uses foo and a view baz that uses bar, I can
add a column to foo without a problem, and, similarly, I can also drop
or alter a column
On Tue, 20 May 2008 19:51:32 +0100 Sam Mason wrote:
> On Tue, May 20, 2008 at 01:20:48PM -0400, Greg Smith wrote:
> > On Tue, 20 May 2008, Hannu Krosing wrote:
> >
> > >Tell others that this trx failed, maybe log a failure ? OTOH, this can
> > >be implemented by a daemon that sits on "tail -f lo
On Wed, 2008-05-21 at 22:04 +0100, Richard Huxton wrote:
> > So ... back to your regularly scheduled development.
>
> Is there a tag in the CVS to mark this point, or better still a tarball
> that people like me can check out and play with over the next month or two?
That's an interesting ide
2008/5/21 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
>> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>> >> In my proposal I don't create any default variables. Result type is
>> >> only virtual - I don't need write it t
Tom Lane wrote:
Per discussion of various hackers at PGCon, the May commitfest is
finished. The remaining patches on the queue are Heikki's map-forks
patch, which was WIP not intended to be committed now; and Merlin
and Andrew's libpq hooks patch, which is still in flux and not
ready to commit n
2008/5/21 Merlin Moncure <[EMAIL PROTECTED]>:
> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>>> In my proposal I don't create any default variables. Result type is
>>> only virtual - I don't need write it to system directory. I thing it's
>>> better than using some spe
2008/5/21 Hannu Krosing <[EMAIL PROTECTED]>:
> On Wed, 2008-05-21 at 18:12 +0200, Pavel Stehule wrote:
>> Hello
>
> ...
>
>> In my proposal I don't create any default variables. Result type is
>> only virtual - I don't need write it to system directory. I thing it's
>> better than using some specif
On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> >> In my proposal I don't create any default variables. Result type is
> >> only virtual - I don't need write it to system directory. I thing it's
> >> better than
Per discussion of various hackers at PGCon, the May commitfest is
finished. The remaining patches on the queue are Heikki's map-forks
patch, which was WIP not intended to be committed now; and Merlin
and Andrew's libpq hooks patch, which is still in flux and not
ready to commit now.
So ... back t
On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>> In my proposal I don't create any default variables. Result type is
>> only virtual - I don't need write it to system directory. I thing it's
>> better than using some specific predeclared type as RESULTTYPE OR
>> RESULTSE
On Wed, 2008-05-21 at 18:12 +0200, Pavel Stehule wrote:
> Hello
...
> In my proposal I don't create any default variables. Result type is
> only virtual - I don't need write it to system directory. I thing it's
> better than using some specific predeclared type as RESULTTYPE OR
> RESULTSET.
How
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> >> Couldn't we just have it pay attention to the existing
>> >> max_stack_depth?
>> >
>> > Recursive query does not consume stack. The server enters an infinite
>> > loop without consuming stack. Stack-depth error does not happen.
>>
>> We could ha
> >> Couldn't we just have it pay attention to the existing
> >> max_stack_depth?
> >
> > Recursive query does not consume stack. The server enters an infinite
> > loop without consuming stack. Stack-depth error does not happen.
>
> We could have a separate guc variable which limits the maximum n
"Yoshiyuki Asaba" <[EMAIL PROTECTED]> writes:
> Hi,
>
> From: David Fetter <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
> Date: Mon, 19 May 2008 04:36:30 -0700
>
>> > > I think it's the other way around. The server should not emit
>> > > infinite number of recor
Hello
I am returning back to my patch and older proposal
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php .
Some work did Neil Conway
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00501.php and
he commited half of this patch - RETURN QUERY part.
Problematic part of my
Hello
I sent rpm package to Devrim and for next two months I am don't will
work on it.
I did some work on sharing code plpgpsm and plpgsql. Without lexer and
parser it can share about 100KB (from 400KB). If we allow callbacks in
parser - it can share about 200KB. But it's need relative massive
re
Hi,
From: David Fetter <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 04:36:30 -0700
> > > I think it's the other way around. The server should not emit
> > > infinite number of records.
> >
> > How about adding new GUC parameter "max_recurs
On Wed, May 21, 2008 at 7:56 AM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-05-21 at 10:40 +0200, Andreas Pflug wrote:
>> Florian Pflug wrote:
>> >
>> > But maybe you could store the whitespace appearing before (or after?)
>> > a token in the parse tree that is stored for a view. That
Hi,
I don't buy the performance argument unless I see some test results
> demonstrating it; exec_prepare_plan is only called on the first invocation
> of a statement. What kind of side-effects could exec_eval_datum call have?
>
Note that I have avoided using the "performance" word for this very
> On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
> > WITH RECURSIVE patch V0.1
> >
> > Here are patches to implement WITH RECURSIVE clause. There are some
> > limitiations and TODO items(see the "Current limitations" section
> > below). Comments are welcome.
> >
> > 1. Credit
> >
Nikhils wrote:
Within exec_prepare_plan there are calls to exec_eval_datum to identify the
argtypes of the involved parameters. However exec_eval_datum actually fills
up value, isnull entries in these cases causing unnecessary additional calls
when all we need is the datum type. Such unnecessary
On Wed, 2008-05-21 at 10:40 +0200, Andreas Pflug wrote:
> Florian Pflug wrote:
> >
> > But maybe you could store the whitespace appearing before (or after?)
> > a token in the parse tree that is stored for a view. That might not
> > allow reconstructing the *precise* statement, but at least the
On Wed, May 21, 2008 at 4:39 AM, Andreas Pflug
<[EMAIL PROTECTED]> wrote:
> Not the whole reason. To get a view definition that is more readable, the
> pretty_bool option of pg_get_viewdef already does some newline and indent
> formatting. Not the initial formatting, but Good Enough (TM), I believe
Florian Pflug wrote:
But maybe you could store the whitespace appearing before (or after?)
a token in the parse tree that is stored for a view. That might not
allow reconstructing the *precise* statement, but at least the
reconstructed statement would preserve newlines and indention - which
25 matches
Mail list logo
