James William Pye writes:
> extern int SPI_execute_statements(const char *src);
> Execute multiple statements. Intended, primarily, for executing one or more
> DDL or DML statements. In contrast with the other execution functions, the
> RPT loop plans and executes the statement before planning
In the event that my plpython3 patch does not make it, it seems prudent to try
and get a *much* smaller patch in to allow the PL to easily exist out of core.
I added a couple SPI functions in order to support the database access
functionality in plpython3u. Also, a getelevel() function for condi
Robert Haas writes:
>> Yeah, this is grotty. It appears that the comment introducing
>> ExecReScan() is somewhat incorrect. It asserts that exprCtxt is used
>> only
> Sigh.
> ...is used only for index scans. However, it's actually also used for
> bitmap scans (both heap and index) and TID sca
On Sat, Dec 19, 2009 at 11:01 PM, Robert Haas wrote:
> On Sat, Dec 19, 2009 at 4:46 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane wrote:
I believe the correct approach is probably to treat values that need to
be propagated into the inner side
On Sat, Dec 19, 2009 at 4:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane wrote:
>>> I believe the correct approach is probably to treat values that need to
>>> be propagated into the inner side as executor parameters. This could
>>> replace the existin
Robert Haas wrote:
> On Sat, Dec 19, 2009 at 10:46 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> > Bruce Momjian wrote:
> >> >> Seems I need some help here.
> >>
> >> I'm willing to work on this --- it doesn't look particularly fun but
> >> we really need it.
> >
> > You don't know fun until y
On Sat, Dec 19, 2009 at 10:46 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> > Bruce Momjian wrote:
>> >> Seems I need some help here.
>>
>> I'm willing to work on this --- it doesn't look particularly fun but
>> we really need it.
>
> You don't know fun until you have tried to stack hack upon hack
Tom Lane wrote:
> > Bruce Momjian wrote:
> >> Seems I need some help here.
>
> I'm willing to work on this --- it doesn't look particularly fun but
> we really need it.
You don't know fun until you have tried to stack hack upon hack and
still create a reliable migration system. :-(
--
Bruce
.
This task is just a homework for me, but the TA may not deep into this problem
and give me such difficult task. That simple idea was very ugly by all
appearances. I'm a freshman to postgres, sorry for that bad idea. Now I've give
up this problem, complaint to TA and try to solve anoth
Here's a patch:
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 6750db8..1276c39 100644
*** a/doc/src/sgml/backup.sgml
--- b/doc/src/sgml/backup.sgml
*** if (!triggered)
*** 2018,2024
!Data Definition Language (DML) - INSERT,
Tom Lane wrote:
> Bruce Momjian writes:
> > ... The idea I had was to create a global structure:
>
> > struct pg_migrator_oids {
> > Oid pg_type;
> > Oid pg_type_array;
> > ...
> > }
>
> > This would initialize to zero as a global structure, an
W dniu 19 grudnia 2009 16:19 użytkownik Jaime Casanova <
jcasa...@systemguards.com.ec> napisał:
>
> i think he is hacking postgres's source code to make the TODO: "allow
> recompilation of views" (he send an email about that in another
> thread)...
>
oh. I didn't realise, that such seemingly simp
> Tatsuo Ishii writes:
> > BTW, why don't lo_creat, lo_create, lo_unlink, lo_import and lo_export
> > server side function's document appear in the "Chapter 9. Functions and
> > Operators" section?
>
> Because large objects have their very own chapter.
Problem is, the chapter is under "Client In
On Sat, Dec 19, 2009 at 1:56 PM, Caleb Welton wrote:
> I maintain that the approaches that inform the user that they have met that
> condition via ALTER statement failures (Postgres/DB2/Microsoft Bound Views)
> have certain advantages over databases that allow the update but may
> silently leave
I wrote:
> In the cases where that's sensible, you can use constraint syntax, no?
> I really doubt that it's that easy to pick a sensible name for an index
> on an expression, for example.
Although, having said that, I realize we just opened that can of worms
with the exclusion-constraint patch:
Robert Haas writes:
> On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane wrote:
>> I believe the correct approach is probably to treat values that need to
>> be propagated into the inner side as executor parameters. This could
>> replace the existing, rather crocky, management of values passed into a
>>
On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> Incidentally, the reason why the executor chokes trying to execute a
>> SRF with an outer reference is because ExecEvalVar() craps out trying
>> to dereference a null TupleTableSlot. If I'm understanding this
>> correctly,
In response to Peter Eisentraut :
> Could we create an option to create index names automatically, so you'd
> only have to write
>
> CREATE INDEX ON foo (a);
>
> which would pick a name like foo_a_idx. We already do this in a number
> of places such as constraint names and sequences without much
Peter Eisentraut writes:
> Could we create an option to create index names automatically, so you'd
> only have to write
> CREATE INDEX ON foo (a);
> which would pick a name like foo_a_idx. We already do this in a number
> of places such as constraint names and sequences without much trouble.
>
A very minor point, but I found when reading dumps it makes more sense
that in the CREATE SEQUENCE command MINVALUE comes before MAXVALUE.
Objections to this patch?
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 9748379..8776e27 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b
On Fri, Dec 18, 2009 at 10:57, Tom Lane wrote:
> Obviously there's something there for the kernel guys to fix, but
> even with a non-borked kernel it's an expensive thing to do.
Any thoughts on back patching this? While its not a bug per-say, it
seems reasonably low-risk. I for one would love a
2009/12/20 Peter Eisentraut :
> Could we create an option to create index names automatically, so you'd
> only have to write
>
> CREATE INDEX ON foo (a);
Yes, please.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
which would pick a name like foo_a_idx. We already do this in a number
of places such as constraint names and sequences without much trouble.
In most cases you don't really need to
Robert Haas writes:
> Incidentally, the reason why the executor chokes trying to execute a
> SRF with an outer reference is because ExecEvalVar() craps out trying
> to dereference a null TupleTableSlot. If I'm understanding this
> correctly, that, in turn, happens because the variable that we're
Marko Tiikkaja writes:
> On 2009-12-15 23:10 +0200, Tom Lane wrote:
>> If we really wanted to take the above seriously, my opinion is that
>> we ought to introduce DISTINCT ON in aggregates.
> FWIW, in my opinion the idea behind this patch is to not fall back on
> hacks like that. This patch al
>Well, that was the criteria I used to decide whether to commit or not.
>Not everyone agreed to begin with, and the reason I used that criteria
>was a selfish one: I didn't want to be forced to fix loose ends after
>the commitfest myself. The big reason for that was that I didn't know
>how much ti
On 2009-12-15 23:10 +0200, Tom Lane wrote:
Andrew Gierth writes:
Notice that there are cases where agg(distinct x order by x) is
nondeterministic while agg(distinct x order by x,y) is deterministic.
Well, I think what you're really describing is a case where you're using
the wrong sort opclas
Hiroyuki Yamada wrote:
>> Hiroyuki Yamada writes:
>>> Well, I want to know whether the problem I refered to
>>> in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
>>> is must-fix or not.
>>> This problem is a corollary of the deadlock problem. This is less
>>> catstrophic
>>> b
I was dealing with a customer recently who very much wanted this behavior,
during discussions with them
I wrote up a little something describing how different database vendors treat
views and alter statements.
...
Part of the issue here is that the SQL Standard does a very poor job of
expressin
On Thu, Dec 17, 2009 at 10:13 PM, Robert Haas wrote:
> Another question I have - while generalizing the inner-indexscan
> machinery is an interesting join optimization technique, I'm thinking
> that it actually has very little to do with LATERAL. Is there any
> reason to suppose that one or the o
2009/12/20 Robert Haas :
> On Sat, Dec 19, 2009 at 12:49 PM, Hitoshi Harada wrote:
>> 2009/10/20 Andrew Gierth :
>>> Right now, the only way pg can plan this is to do a hashjoin or
>>> mergejoin of the _entire content of big1 and big2_ and join the
>>> result against "small" (again in a hashjoin o
On Sat, Dec 19, 2009 at 12:49 PM, Hitoshi Harada wrote:
> 2009/10/20 Andrew Gierth :
>> Right now, the only way pg can plan this is to do a hashjoin or
>> mergejoin of the _entire content of big1 and big2_ and join the
>> result against "small" (again in a hashjoin or mergejoin plan).
>> This beco
2009/10/20 Andrew Gierth :
> Right now, the only way pg can plan this is to do a hashjoin or
> mergejoin of the _entire content of big1 and big2_ and join the
> result against "small" (again in a hashjoin or mergejoin plan).
> This becomes excessively slow compared to the "ideal" plan:
>
> nested
>Hiroyuki Yamada writes:
>> Well, I want to know whether the problem I refered to
>> in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
>> is must-fix or not.
>
>> This problem is a corollary of the deadlock problem. This is less catstrophic
>> but more likely to happen.
>
>> I
On Sat, 2009-12-19 at 18:12 +0100, Stefan Kaltenbrunner wrote:
> > Seems like something we should fix ASAP, but I do not see why it
> need
> > hold up an alpha release. Alpha releases are expected to have bugs,
> > and this one doesn't look like it would stop people from finding
> > other bugs.
>
Robert Haas wrote:
I think (as I did/do with Hot Standby) that the most important thing
here is to get to a point where we have a reasonably good feature that
is of some use, and commit it. It will probably have some annoying
limitations; we can remove those later. I have a feel that what we
ha
Tom Lane wrote:
Hiroyuki Yamada writes:
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is must-fix or not.
This problem is a corollary of the deadlock problem. This is less catstrophic
but more likely to happen.
Hiroyuki Yamada writes:
> Well, I want to know whether the problem I refered to
> in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
> is must-fix or not.
> This problem is a corollary of the deadlock problem. This is less catstrophic
> but more likely to happen.
> If you leav
Tatsuo Ishii writes:
> BTW, why don't lo_creat, lo_create, lo_unlink, lo_import and lo_export
> server side function's document appear in the "Chapter 9. Functions and
> Operators" section?
Because large objects have their very own chapter.
> Shall I add them?
No, I don't think we should docume
On Sat, Dec 19, 2009 at 7:20 AM, Peter Eisentraut wrote:
> Do people want more time to play with hot standby? Otherwise alpha3
> should go out on Monday or Tuesday.
I think we should try to wrap it promptly. It's true that Hot Standby
almost certainly has bugs and/or annoying limitations, as on
Tom Lane wrote:
I think that there are two likely possibilities for the result format:
* "Raw" data after just the de-escaping and column separation steps.
Array of text is probably the right thing here, at least for a text COPY
(doesn't seem to cover the binary case though).
* The data conve
2009/12/19 Filip Rembiałkowski :
>
> W dniu 19 grudnia 2009 03:20 użytkownik suzhiyang
> napisał:
>>
>> Sorry, I've not describe my problem precisely.
>> I mean that I want to get relkind or something from a systable by the
>> programm but not by sql.
>
> I don't understand how you can get data f
On Sat, Dec 19, 2009 at 8:44 AM, Dimitri Fontaine
wrote:
> Le 19 déc. 2009 à 03:01, Robert Haas a écrit :
>> On Fri, Dec 18, 2009 at 8:32 PM, Simon Riggs wrote:
>>> Log Message:
>>> ---
>>> Allow read only connections during recovery, known as Hot Standby.
>>
>> Congratulations! And, may
>Do people want more time to play with hot standby? Otherwise alpha3
>should go out on Monday or Tuesday.
>
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is must-fix or not.
This problem is a corollary of the deadlock
Le 19 déc. 2009 à 03:01, Robert Haas a écrit :
> On Fri, Dec 18, 2009 at 8:32 PM, Simon Riggs wrote:
>> Log Message:
>> ---
>> Allow read only connections during recovery, known as Hot Standby.
>
> Congratulations! And, may I be the first to say - woo hoo!
+1!
--
dim
--
Sent via pgsq
W dniu 19 grudnia 2009 03:20 użytkownik suzhiyang napisał:
> Sorry, I've not describe my problem precisely.
> I mean that I want to get relkind or something from a systable by the
> programm but not by sql.
>
I don't understand how you can get data from table without using SQL. (maybe
I'm just "
Do people want more time to play with hot standby? Otherwise alpha3
should go out on Monday or Tuesday.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Dec 19, 2009, at 4:07 AM, Dave Page wrote:
Thanks Greg - nice job! :-)
+1!
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks Greg - nice job! :-)
On Sat, Dec 19, 2009 at 7:30 AM, Greg Smith wrote:
> CommitFest 2009-11 is now closed, having committed 27 patches in 33 days.
> For comparison sake, 2009-09 committed 20 patches in 29 days, 2009-07 37
> patches in 34 days, and 2008-09 29 patches in 30 days. The much
49 matches
Mail list logo
