2010/1/23 Robert Haas :
> On Tue, Jan 19, 2010 at 3:02 PM, Hitoshi Harada wrote:
>> 2010/1/19 Hitoshi Harada :
>>> Yeah, that's my point, too. The planner has to distinguish "four" from
>>> sort pathkeys and to teach the executor the simple information which
>>> column should be used to determine
(2010/01/23 5:12), Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached patch is a revised version.
>
> I'm inclined to wonder whether this patch doesn't prove that we've
> reached the end of the line for the current representation of blobs
> in pg_dump archives. The alternative that I'm think
(2010/01/23 1:27), Robert Haas wrote:
So, what if we treat these two cases separately? The part-B checks -
on the other operations involved in ALTER TABLE - are by definition
idiosyncratic. What type of object we're checking and what permission
we're checking for is inextricably bound up with w
think also how people use SQL word , when calling ms sql server. They would
just say 'sql server' , and to some I had to explain that the little greedy
company didn't actually invented sql, hence it should be called ms sql
server...
so, -1 for dropping SQL word from me.
... and maybe the shed
2010/1/23 Andrew Chernow :
> Tom Lane wrote:
>>
>> "David E. Wheeler" writes:
>>>
>>> On Jan 22, 2010, at 4:54 PM, Mark Mielke wrote:
MS SQL, MySQL, SQLite - do they have advocacy problems due to the SQL in
their name? I think it is the opposite. SQL in the name almost grants
l
Tom Lane wrote:
"David E. Wheeler" writes:
On Jan 22, 2010, at 4:54 PM, Mark Mielke wrote:
MS SQL, MySQL, SQLite - do they have advocacy problems due to the SQL in their
name? I think it is the opposite. SQL in the name almost grants legitimacy to
them as products. Dropping the SQL has the p
"David E. Wheeler" writes:
> On Jan 22, 2010, at 4:54 PM, Mark Mielke wrote:
>> MS SQL, MySQL, SQLite - do they have advocacy problems due to the SQL in
>> their name? I think it is the opposite. SQL in the name almost grants
>> legitimacy to them as products. Dropping the SQL has the potential
I was just poking at the test case provided by Allen Johnson in bug
#5294. The essence of the complaint is that the planner is choosing
a sort-and-GroupAggregate plan when a HashAggregate-and-then-sort
plan would be faster, because the aggregation steps are roughly the
same speed either way while
On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> - Allow (ineffective) use of 'require' in plperl
> If the required module is not already loaded then it dies.
> So "use strict;" now works in plperl.
[ BTW I think this is awesome! ]
Id vote for use warnings; as well.
> - Stored procedure
On Jan 22, 2010, at 4:54 PM, Mark Mielke wrote:
> MS SQL, MySQL, SQLite - do they have advocacy problems due to the SQL in
> their name? I think it is the opposite. SQL in the name almost grants
> legitimacy to them as products. Dropping the SQL has the potential to
> increase confusion. What i
On Fri, Jan 22, 2010 at 7:50 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
>>> Any ideas?
>
>> The lower bound on the release cycle is about 12 months right now
>> because we intend to support old versions for 5 years, and 5 or 6
>> branch
Tom Lane wrote:
Another problem is that it's very debatable whether users (as opposed
to developers) want a fast release cycle. Some of that reluctance to
update might dissipate if we had a better upgrade-in-place story, but
by no means all of it. People don't want to have to retest their
app
On 01/22/2010 10:57 AM, Aidan Van Dyk wrote:
* Brendan Jurd [100122 10:29]:
Holy query language, Batman!
Do you mean to tell me that the "uninformed masses" you interact with
have an understanding of what "SQL" means?
I am skeptical of this claim, but if true, you must have access to the
Peter Eisentraut writes:
> On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
>> Any ideas?
> The lower bound on the release cycle is about 12 months right now
> because we intend to support old versions for 5 years, and 5 or 6
> branches at once is about the most anyone can handle. That form
On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
> and start talking about
> how we can create an environment where patch authors can get their
> work committed reasonably quickly (assuming it's good, of course) and
> released within some reasonable time frame after that (like, say,
> within a
Buenos Dias todos,
Soy un usuario de postgres de Paraguay,
consulto sobre la posibilidad de inclucion en la futura version la
siguiente sentencia(Uso de alias en la condicion HAVING ):
SELECT id, sum(salario) as SumaSalario
FROM salarios
GROUP BY id
On Fri, Jan 22, 2010 at 5:15 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I think feature freeze should be the beginning of the last CommitFest,
>> not the end.
>
> So you still want 3 CF per cycle rather than 4?
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg02355.php
>
> 3 C
"Kevin Grittner" wrote:
> I'll get started.
After a couple false starts, the creation of the millions of tables
is underway. At the rate it's going, it won't finish for 8.2 hours,
so I'll have to come in and test the dump tomorrow morning.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsq
Robert Haas writes:
> I think feature freeze should be the beginning of the last CommitFest,
> not the end.
So you still want 3 CF per cycle rather than 4?
http://archives.postgresql.org/pgsql-hackers/2009-12/msg02355.php
3 CF and a FixFest… -1 from me, if there's an open vote to be made here.
On a Windows server under heavy load of NOTIFY events, entries in
pg_listener table for some events are deleted. It is like UNLISTEN was
called.
PostgreSQL version: 8.3.9.
Operating System: Windows XP.
PostgreSQL believes that if it fails to notify a listener (by signaling
the respective backend)
Tom Lane wrote:
> Empty is fine.
I'll get started.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Do you have the opportunity to try an experiment on hardware
>> similar to what you're running that on? Create a database with 7
>> million tables and see what the dump/restore times are like, and
>> whether pg_dump/pg_restore appear to be CPU-bound
Tom Lane wrote:
> Do you have the opportunity to try an experiment on hardware
> similar to what you're running that on? Create a database with 7
> million tables and see what the dump/restore times are like, and
> whether pg_dump/pg_restore appear to be CPU-bound or
> memory-limited when doing
"Kevin Grittner" writes:
> Tom Lane wrote:
>> We've heard of people with many tens of thousands of
>> tables, and pg_dump speed didn't seem to be a huge bottleneck for
>> them (at least not in recent versions). So I'm feeling we should
>> not dismiss the idea of one TOC entry per blob.
>>
>> Th
Tom Lane wrote:
> Now the argument against that is that it won't scale terribly well
> to situations with very large numbers of blobs. However, I'm not
> convinced that the current approach of cramming them all into one
> TOC entry scales so well either. If your large objects are
> actually la
KaiGai Kohei writes:
> The attached patch is a revised version.
I'm inclined to wonder whether this patch doesn't prove that we've
reached the end of the line for the current representation of blobs
in pg_dump archives. The alternative that I'm thinking about is to
treat each blob as an independ
On Tue, Jan 19, 2010 at 3:02 PM, Hitoshi Harada wrote:
> 2010/1/19 Hitoshi Harada :
>> Yeah, that's my point, too. The planner has to distinguish "four" from
>> sort pathkeys and to teach the executor the simple information which
>> column should be used to determine frame. I was bit wrong because
"Kevin Grittner" writes:
> So add me to the list of people who think that if
> these are going to be recurring, we should look at moving from cvs
> to git as soon as 9.0 is released.
The gating factor is not release schedule; it is the still-unaddressed
tasks that must be done before we can consi
On Fri, Jan 22, 2010 at 7:19 AM, Pavel Stehule wrote:
> here is new variant. Add scan_state flag "valid" and enhance
> protection against execution broken statement.
This doesn't make sense to me. You've changed the way \set is handled
- in a way that doesn't seem particularly appropriate to me
Pavel,
My review of your listagg patch.
Submission Review
-
* The diff is a context diff and applies cleanly to HEAD (with just two hunks
offset by 2 lines each).
* There is documentation, though I'm not sure it needs to be mentioned in the
string functions documentation. No ha
Leonardo F writes:
> Would it make sense to use
> FormIndexDatum
> to get the index value to be used by tuplesort?
That would probably work. You might want to look at the code associated
with the recently-added exclusion constraint feature; that also has a
need to reproduce index entries sometim
On Thu, Jan 21, 2010 at 10:24 AM, Alex Hunsaker wrote:
> On Thu, Jan 21, 2010 at 07:30, Robert Haas wrote:
>> On Thu, Jan 21, 2010 at 12:57 AM, Alex Hunsaker wrote:
>>> Seems to me a comment about the above might be nice. Something like
>>> /* Things after here are should always be default null
> Note you should be looking at pg_am.amcanorder, not
> hardwiring knowledge of particular index types.
Ok.
Would it make sense to use
FormIndexDatum
to get the index value to be used by tuplesort?
I'm having trouble avoiding the call to _bt_mkscankey_nodata
to get the scanKeys... that relat
2010/1/22 Tom Lane :
> Robert Haas writes:
>> 2010/1/22 Devrim GÜNDÜZ :
>>> I think this broke doc builds:
>
>> Dang, how'd that happen? I could have sworn I tested this.
>
> Some versions of docbook are pickier than others --- maybe yours
> didn't complain?
It's complaining now, so I don't thin
Leonardo F writes:
> gist -> how can I get something "comparable" by tuplesort? Or should I rule it
>out from the seq scan + sort path?
Rule it out. Note you should be looking at pg_am.amcanorder, not
hardwiring knowledge of particular index types.
regards, tom lane
Robert Haas writes:
> 2010/1/22 Devrim GÜNDÜZ :
>> I think this broke doc builds:
> Dang, how'd that happen? I could have sworn I tested this.
Some versions of docbook are pickier than others --- maybe yours
didn't complain?
regards, tom lane
--
Sent via pgsql-hackers
2010/1/22 Devrim GÜNDÜZ :
> On Fri, 2010-01-22 at 16:40 +, Robert Haas wrote:
>> Log Message:
>> ---
>> Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general
>> mechanism.
>
> I think this broke doc builds:
Dang, how'd that happen? I could have sworn I tested this.
Will
On Fri, 2010-01-22 at 16:40 +, Robert Haas wrote:
> Log Message:
> ---
> Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general
> mechanism.
I think this broke doc builds:
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c
/usr/share/sgml/docbook/d
Michael Meskes írta:
>> diff -dcrpN
>> pgsql.orig/src/interfaces/ecpg/test/expected/compat_informix-struct.c
>> pgsql.4.1/src/interfaces/ecpg/test/expected/compat_informix-struct.c
>> ...
>> +/* Test DECLARE ... SELECT ... INTO with struct type */
>> +
>> +ECPGset_var( 0, &( myvar ), __L
Simon Riggs writes:
> So a "dynamic query hook". When called, the hook would give access to
> the query text actually executed. Existing plugins wouldn't know about
> the hook, so would never call it, so the language run time would bypass
> that hook altogether. Newer versions of plugins would be
"Kevin Grittner" wrote:
> I just updated my source code and it no longer seems to work to type
> the following, and I'm pretty sure I was using it with a checkout
> from less than 24 hours ago:
Never mind. My mistake.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
I just updated my source code and it no longer seems to work to type
the following, and I'm pretty sure I was using it with a checkout
from less than 24 hours ago:
select * from pg_lo[Tab]
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On Fri, 2010-01-22 at 11:33 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Anyway, there already was another way of doing this, so it shall be done
> > that way instead. The beauty of a pluggable architecture is that one
> > does not need approval to implement customer solutions.
>
> If you're
Robert Haas writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't particularly like this patch, mainly because I disagree with
randomly removing permissions checks without any sort of plan about
where they ought to go.
> [ a plan for rearranging ALTER TABLE's checks ]
Works fo
So, if I'm not mistaken:
hash indexes -> can't be used in CLUSTER
gin indexes -> can't be used in CLUSTER
that leaves:
btree -> ok
expression btree -> I have to find a way to compute the expression for
each tuple: hints?
gist -> how can I get something "comparable" by tuplesort? Or should I r
Alexey Klyukin wrote:
On Jan 22, 2010, at 4:38 PM, Robert Haas wrote:
On Fri, Jan 22, 2010 at 9:13 AM, Alexey Klyukin wrote:
I think elog(WARNING) is less surprising for the end-user, unless there's an
objection strong enough to include it into the documentation :)
I think
Simon Riggs writes:
> Anyway, there already was another way of doing this, so it shall be done
> that way instead. The beauty of a pluggable architecture is that one
> does not need approval to implement customer solutions.
If you're talking about a bundle that you're shipping to customers,
of co
On Fri, Jan 22, 2010 at 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not sure whether you're stating a position that's been agreed to
>> by -core or some other group, or just expressing your own opinion, but
>> I think feature freeze should be the beginning of the last CommitFest,
>> no
On Thu, Dec 17, 2009 at 10:09 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> KaiGai Kohei writes:
>> > [ patch to remove EnableDisableRule's permissions check ]
>>
>> I don't particularly like this patch, mainly because I disagree with
>> randomly removing permissions checks
On Fri, 2010-01-22 at 10:56 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > It's not currently possible to access the SQL used in a dynamic PL/pgSQL
> > statement using a PL/pgSQL plugin.
>
> > In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
> > statement type, evaluate the SQ
Robert Haas writes:
> I'm not sure whether you're stating a position that's been agreed to
> by -core or some other group, or just expressing your own opinion, but
> I think feature freeze should be the beginning of the last CommitFest,
> not the end.
I think traditionally we understood "feature
* Brendan Jurd [100122 10:29]:
> Holy query language, Batman!
>
> Do you mean to tell me that the "uninformed masses" you interact with
> have an understanding of what "SQL" means?
>
> I am skeptical of this claim, but if true, you must have access to the
> most spectacularly informed "uninfor
Simon Riggs writes:
> It's not currently possible to access the SQL used in a dynamic PL/pgSQL
> statement using a PL/pgSQL plugin.
> In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
> statement type, evaluate the SQL and free memory again before the plugin
> gains control again
On Fri, Jan 22, 2010 at 2:37 PM, Kevin Grittner
wrote:
>
> I think I have some recall of improvements to that in the 8.4
> release, so an upgrade might help.
There was a standalone program which you can call from your recovery
script to prefetch the blocks needed to replay the next log file
befor
On tis, 2009-11-17 at 18:48 +0200, Valtonen, Hannu wrote:
> The attached patch adds support for DO clause in plpythonu. It was
> heavily inspired by the plperl and plpgsql inline handler code.
committed
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On Jan 22, 2010, at 4:38 PM, Robert Haas wrote:
> On Fri, Jan 22, 2010 at 9:13 AM, Alexey Klyukin wrote:
>> I think elog(WARNING) is less surprising for the end-user, unless there's an
>> objection strong enough to include it into the documentation :)
>
> I think the main possible objection wo
2010/1/23 Mark Mielke :
> Calling it
> "PostgreSQL", makes it very clear to the uninformed masses where the product
> fits in a product map. Tell an executive of a company "Postgres", and they
> would ask "what is it?" Tell them "PostgreSQL", and they'll say "is that
> like Oracle?" The second is h
On 01/22/2010 09:52 AM, Greg Sabino Mullane wrote:
Well, this *was* posted to -hackers and not -advocacy, but
advocacy, mind share, and many other non-hacking-on-the-base-code things
matter too. And frankly, our name is one of our *top* problems.
Perhaps you've never had to explain to non-techni
On fre, 2010-01-22 at 15:10 +, Simon Riggs wrote:
> I merely ask that you consider the non-zero cost of such changes as
> well
> as the benefit. Not all change is worthwhile, even if the change can
> be
> made quickly and with little effect on the stability of the software.
Right, that's why I
On Fri, 2010-01-22 at 16:50 +0200, Peter Eisentraut wrote:
> On fre, 2010-01-22 at 14:22 +, Simon Riggs wrote:
> > "Stable software" isn't just software that doesn't break, it requires
> > IIABDFI as well.
>
> Yeah, I don't buy that. That would mean that you can never do
> maintenance, refact
> diff -dcrpN
> pgsql.orig/src/interfaces/ecpg/test/expected/compat_informix-struct.c
> pgsql.4.1/src/interfaces/ecpg/test/expected/compat_informix-struct.c
> ...
> + /* Test DECLARE ... SELECT ... INTO with struct type */
> +
> + ECPGset_var( 0, &( myvar ), __LINE__);\
> + ECPGset_var(
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> As far as I can see, there is absolutely zero reason to care about
> whether the product is called Postgres or PostgreSQL.
Sorry, but names matter. Advoca
On fre, 2010-01-22 at 14:22 +, Simon Riggs wrote:
> "Stable software" isn't just software that doesn't break, it requires
> IIABDFI as well.
Yeah, I don't buy that. That would mean that you can never do
maintenance, refactoring, or polishing. You basically just wait for the
system to die a d
2010/1/22 Devrim GÜNDÜZ :
> On Fri, 2010-01-22 at 09:10 -0500, Robert Haas wrote:
>> I'm not sure whether you're stating a position that's been agreed to
>> by -core or some other group, or just expressing your own opinion, but
>> I think feature freeze should be the beginning of the last CommitFes
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>>> Why does warn; in plperl log as NOTICE in Postgres?
> *shrug* I don't have a strong opinion about it, and it's pretty easy to
> change, if there's a consensus we should. I have certainly found over
> the years that perl warnings from some mo
On Fri, Jan 22, 2010 at 9:13 AM, Alexey Klyukin wrote:
> I think elog(WARNING) is less surprising for the end-user, unless there's an
> objection strong enough to include it into the documentation :)
I think the main possible objection would what Simon just wrote on the
other thread - that it's
"Huda Booley (h...@careerjunction.co.za)"
wrote:
> These get copied to the standby so its all there, just not being
> applied fast enough.
If the files are there and are not applying fast enough, it's
probably because on the source machine you can have multiple
connections submitting data modi
On Fri, Jan 22, 2010 at 9:22 AM, Simon Riggs wrote:
> On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote:
>> On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
>> > Robert Haas writes:
>> > > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut
>> > > wrote:
>> > >> Here is a small patch th
On Fri, 2010-01-22 at 09:10 -0500, Robert Haas wrote:
> I'm not sure whether you're stating a position that's been agreed to
> by -core or some other group, or just expressing your own opinion, but
> I think feature freeze should be the beginning of the last CommitFest,
> not the end.
Was is decl
Robert Haas wrote:
On Fri, Jan 22, 2010 at 8:40 AM, Peter Eisentraut wrote:
On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
Well, we used to have the idea of a feature freeze ... is that going
to apply at the end of the commitfest?
Feature freeze was used to discoura
On Thu, 2010-01-21 at 23:22 +0200, Peter Eisentraut wrote:
> On tor, 2010-01-21 at 15:51 -0500, Tom Lane wrote:
> > Robert Haas writes:
> > > On Thu, Jan 21, 2010 at 3:30 PM, Peter Eisentraut wrote:
> > >> Here is a small patch that changes the error message
> > >>
> > >> duplicate key value vi
On Jan 22, 2010, at 2:55 AM, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Andrew Dunstan writes:
>>
>>> Jim Nasby wrote:
>>>
Why does warn; in plperl log as NOTICE in Postgres?
>>
>>
>>> Where would you like the warning to go? This has been this way for nearly 5
>>>
On Thu, Jan 21, 2010 at 4:19 PM, Tom Lane wrote:
> You're poking into a data structure you shouldn't be poking into:
>
> /* Plans are opaque structs for standard users of SPI */
> typedef struct _SPI_plan *SPIPlanPtr;
>
> I hardly think that keeping yourself at arm's length from the planner
> by g
Takahiro-san,
> Good. I think the patch is ready to commit.
Thanks for reviewing it. I just committed the patch.
> A comment for committer (Michael?) :
> I was cofused by the AddStmtToCache's 2nd argument "char *stmtID"
> because it doesn't have a const. Should it be "const char *" ?
> If the ar
On Fri, Jan 22, 2010 at 8:40 AM, Peter Eisentraut wrote:
> On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
>> Well, we used to have the idea of a feature freeze ... is that going
>> to apply at the end of the commitfest?
>
> Feature freeze was used to discourage the submission of very big
On tor, 2010-01-21 at 19:45 -0500, Robert Haas wrote:
> Well, that does seem to be endorsing a sort of two-tiered system.
In those words, yes, it's a multi-tiered system. The aim of the commit
fests is to make the "lower" tier more effective, but not necessarily to
bring the "upper" tier to a nea
On tor, 2010-01-21 at 18:05 -0500, Andrew Dunstan wrote:
> Well, we used to have the idea of a feature freeze ... is that going
> to apply at the end of the commitfest?
Feature freeze was used to discourage the submission of very big patches
shortly before beta. The commit fest process has IMO al
On Thu, Jan 21, 2010 at 07:55:09PM -0500, Andrew Dunstan wrote:
> Tom Lane wrote:
> >Andrew Dunstan writes:
> >>Jim Nasby wrote:
> >>>Why does warn; in plperl log as NOTICE in Postgres?
> >
> >>Where would you like the warning to go? This has been this way
> >>for nearly 5 years, it's not new (and
Hello
here is new variant. Add scan_state flag "valid" and enhance
protection against execution broken statement.
Regards
Pavel Stehule
2010/1/22 Pavel Stehule :
> 2010/1/22 Robert Haas :
>> On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule
>> wrote:
>>> 2010/1/21 Robert Haas :
On Thu, Jan 2
On Fri, 2010-01-22 at 13:39 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It's not currently possible to access the SQL used in a dynamic PL/pgSQL
> > statement using a PL/pgSQL plugin.
> >
> > In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
> > statement type, evalu
Simon Riggs wrote:
> It's not currently possible to access the SQL used in a dynamic PL/pgSQL
> statement using a PL/pgSQL plugin.
>
> In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
> statement type, evaluate the SQL and free memory again before the plugin
> gains control again
Marko Kreen wrote:
> On 1/22/10, Dimitri Fontaine wrote:
>> Heikki Linnakangas writes:
>> > The problem only applies to libpq calls from the backend. Client apps
>> > are not affected, only backend modules. If there's any other modules out
>> > there that use libpq, then yes, those have a prob
On Fri, 2010-01-22 at 11:41 +0100, Pavel Stehule wrote:
> 2010/1/22 Simon Riggs :
> >
> > It's not currently possible to access the SQL used in a dynamic PL/pgSQL
> > statement using a PL/pgSQL plugin.
> >
> > In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
> > statement type, ev
2010/1/22 Simon Riggs :
>
> It's not currently possible to access the SQL used in a dynamic PL/pgSQL
> statement using a PL/pgSQL plugin.
>
> In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
> statement type, evaluate the SQL and free memory again before the plugin
> gains control
It's not currently possible to access the SQL used in a dynamic PL/pgSQL
statement using a PL/pgSQL plugin.
In src/pl/plpgsql/src/pl_exec.c's exec_stmt() we call each dynamic
statement type, evaluate the SQL and free memory again before the plugin
gains control again.
It seems simple to attach q
On 1/22/10, Dimitri Fontaine wrote:
> Heikki Linnakangas writes:
>
> > Joe Conway wrote:
> >> OK, so now I see why we want this fixed for dblink and walreceiver, but
> >> doesn't this approach leave every other WIN32 libpq client out in the
> >> cold? Is there nothing that can be done for the
Heikki Linnakangas writes:
> Joe Conway wrote:
>> OK, so now I see why we want this fixed for dblink and walreceiver, but
>> doesn't this approach leave every other WIN32 libpq client out in the
>> cold? Is there nothing that can be done for the general case, or is it a
>> SMOP?
>
> The problem o
Hi
We are running postgres8.3.9 and have enabled log shipping replication. Our
standby server is about 1000 files BEHIND - everything I've read indicates that
the standby server should be very close behind the live server - at the rate
we're going it will take 8 hours to apply all the logs to s
> > So my proposal would be: do the test seq_scan vs sort/index_scan only for
> > regular btree index, and integrate that test in the planner.
>
> Keep in mind that this patch was after the deadline for 9.0, so there
> is probably not a huge rush to get this done.
That's true; I'll try to get th
On Friday 22. January 2010 01.22.09 Tom Lane wrote:
> "Larry Rosenman" writes:
> > On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote:
> >> Care to shed some light on what features (yes, we users care about
> >> features) warrant this major version-bump? Is there a link somewhere?
>
> >
90 matches
Mail list logo
