Fujii Masao wrote:
> OK. Here is the patch which supports a walsender process during recovery;
>
> * Change walsender so as to send the WAL written by the walreceiver
> if it has been started during recovery.
> * Kill the walsenders started during recovery at the end of recovery
> because repl
Fujii Masao wrote:
> Since I had tweaked wal-skipping logic for SR before,
> there were two additional changes about that;
> http://archives.postgresql.org/pgsql-committers/2009-11/msg00018.php
> http://archives.postgresql.org/pgsql-committers/2009-12/msg00167.php
>
> The attached patch deals with
On 01/26/2010 02:55 PM, Guillaume Lelarge wrote:
> Le 26/01/2010 19:43, Joe Conway a écrit :
>> On 01/25/2010 03:21 PM, Guillaume Lelarge wrote:
>>> I didn't put any documentation before knowing which one will be choosen.
>>> So we still need to work on the manual.
>>
>> Please send the documentati
Robert Haas wrote:
Waiting for Initial Review (4)
==
plpython3 - no reviewer yet
This whole feature seems quite interesting, and I'm really impressed at
how much work James has put into rethinking what a Python PL should look
like. But isn't the fact that there isn
On Jan 27, 2010, at 6:47 PM, Takahiro Itagaki wrote:
> * I think we cannot cache the delimiter at the first call.
> For example,
>SELECT string_agg(elem, delim)
> FROM (VALUES('A', ','), ('B', '+'), ('C', '*')) t(elem, delim);
> should return 'A+B*C' rather than 'A,B,C'.
Ooh, nice.
>
Pavel Stehule wrote:
> with actualised oids
I'm checking the patch for commit, and have a couple of comments.
* I think we cannot cache the delimiter at the first call.
For example,
SELECT string_agg(elem, delim)
FROM (VALUES('A', ','), ('B', '+'), ('C', '*')) t(elem, delim);
sho
Alvaro Herrera wrote:
"make world" sounds reasonable and I've remember seeing it elsewhere.
Here's a simple patch. Comments?
cheers
andrew
Index: GNUmakefile.in
===
RCS file: /cvsroot/pgsql/GNUmakefile.in,v
retrieving revisi
The attached patch uses one TOC entry for each blob objects.
It adds two new section types.
* "BLOB ITEM"
This section provides properties of a certain large object.
It contains a query to create an empty large object, and restore
ownership of the large object, if necessary.
| --
| -- Name: 1
(2010/01/28 6:58), Robert Haas wrote:
> On Wed, Jan 27, 2010 at 3:42 PM, Robert Haas wrote:
>> On Wed, Jan 27, 2010 at 10:17 AM, KaiGai Kohei wrote:
>>> (2010/01/27 23:29), Robert Haas wrote:
2010/1/27 KaiGai Kohei:
>
> The attached patch is revised one based on the V3 approach.
On Tue, Jan 26, 2010 at 11:03 PM, Greg Smith wrote:
> Tom Lane wrote:
>>
>> Right, but the question is: is there enough use-case left in it to
>> justify spending community effort on polishing rough edges? It's not
>> like we haven't got plenty else to do to get 9.0 out the door.
>>
>
> The point
On Thu, Jan 28, 2010 at 9:32 AM, Erik Rijkers wrote:
> On Wed, January 27, 2010 17:38, Heikki Linnakangas wrote:
>
>> I'll commit it that way.
Thanks Heikki! Yeah, your approach makes more sense.
> This is just to let you know that these commits seem to have solved the bug.
Good! Thanks Erik!
Greg Smith wrote:
> Alvaro Herrera wrote:
> >Greg Smith wrote:
> >>The archives are at
> >>http://archives.postgresql.org/pgsql-cluster-hackers/ but it's not
> >>listed at http://archives.postgresql.org/ for some reason.
> >
> >Because it wasn't added to the database. It seems we've gotten sloppy
David E. Wheeler wrote:
> On Jan 27, 2010, at 2:38 PM, Tom Lane wrote:
>
> > These proposals sound reasonable to me too, but is "everything" an
> > appropriate target name, or is there some other/better convention?
>
> Oooh, more bike-shedding.
>
> make theworld
> make toutlemonde
"make
Tom Lane wrote:
It's obvious that the people who want this are entirely willing
to adopt a Pollyanna-ishly optimistic view about its potential
to cause serious problems that we may or may not be able to fix.
I don't really expect to be able to prevent something along this line
from getting com
On Jan 27, 2010, at 7:58 AM, Pavel Stehule wrote:
> with actualised oids
Thanks. Looks good, modulo my preference for concat_agg(). I'll mark it ready
for committer.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
(2010/01/28 5:42), Robert Haas wrote:
> On Wed, Jan 27, 2010 at 10:17 AM, KaiGai Kohei wrote:
>> (2010/01/27 23:29), Robert Haas wrote:
>>>
>>> 2010/1/27 KaiGai Kohei:
The attached patch is revised one based on the V3 approach.
The only difference from V3 is that it also applies che
On Jan 27, 2010, at 4:33 PM, Tom Lane wrote:
> [ shrug...] I see little point in repeating myself yet again.
> It's obvious that the people who want this are entirely willing
> to adopt a Pollyanna-ishly optimistic view about its potential
> to cause serious problems that we may or may not be abl
"David E. Wheeler" writes:
> On Jan 27, 2010, at 4:15 PM, Tom Lane wrote:
>> Sure. Which is why I'm resisting expanding our exposure to it
> I don't understand how it's expanding core's exposure to it.
[ shrug...] I see little point in repeating myself yet again.
It's obvious that the people w
On Wed, January 27, 2010 17:38, Heikki Linnakangas wrote:
> I'll commit it that way.
This is just to let you know that these commits seem to have solved the bug.
I repeated the original test (700 MB pg_restore into a primary,
with two replicating slaves, on one machine).
Checking afterwards:
$
On Jan 27, 2010, at 4:15 PM, Tom Lane wrote:
>> Is that not the case with plperlu already?
>
> Sure. Which is why I'm resisting expanding our exposure to it
I don't understand how it's expanding core's exposure to it.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
"David E. Wheeler" writes:
> On Jan 27, 2010, at 4:10 PM, Tom Lane wrote:
>> Absolutely. The difference here is in who is going to be expected to
>> try to deal with any problems. When somebody says "if I do this in
>> plperlu, my database crashes! Postgres sux!" it's not going to help to
>> sa
Tom Lane wrote:
"David E. Wheeler" writes:
On Jan 27, 2010, at 3:33 PM, Tom Lane wrote:
I don't have to read any further than the place where it says "doesn't
work if you call both plperl and plperlu" to realize that that's quite
false. Maybe we have different definitions of what a
On Jan 27, 2010, at 4:10 PM, Tom Lane wrote:
> Absolutely. The difference here is in who is going to be expected to
> try to deal with any problems. When somebody says "if I do this in
> plperlu, my database crashes! Postgres sux!" it's not going to help to
> say "that's a Perl bug", even if an
"David E. Wheeler" writes:
> On Jan 27, 2010, at 3:11 PM, Tom Lane wrote:
>> ... Anything that Perl does to libc
>> state, open file handles, etc etc carries a high risk of breaking the
>> backend.
> As could any other code that executes then, including C libraries installed
> from pgFoundry an
"David E. Wheeler" writes:
> On Jan 27, 2010, at 3:33 PM, Tom Lane wrote:
>> I don't have to read any further than the place where it says "doesn't
>> work if you call both plperl and plperlu" to realize that that's quite
>> false. Maybe we have different definitions of what a software
>> interac
On Jan 27, 2010, at 3:33 PM, Tom Lane wrote:
> I don't have to read any further than the place where it says "doesn't
> work if you call both plperl and plperlu" to realize that that's quite
> false. Maybe we have different definitions of what a software
> interaction is...
I think that dates fr
Tim Bunce writes:
> On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
>> Really? We've found that gprof, for instance, doesn't exactly have
>> "zero interaction with the rest of the backend" --- there's actually
>> a couple of different bits in there to help it along, including a
>> behav
On Jan 27, 2010, at 3:11 PM, Tom Lane wrote:
> You still aren't letting go of the notion that Perl could only affect
> the rest of the backend via SPI. The point I'm trying to impress on you
> is that there are any number of other possible pathways, and that Perl's
> historical assumption that it
Tim Bunce writes:
> Okay. I could change the callback code to ignore calls if
> proc_exit_inprogress is false. So an abnormal shutdown via exit()
> wouldn't involve plperl at all. (Alternatively I could use use
> on_proc_exit() instead of atexit() to register the callback.)
Use on_proc_exit pleas
"David E. Wheeler" writes:
> On Jan 27, 2010, at 1:53 PM, Robert Haas wrote:
>> What exactly do we mean by "system-level actions"? I mean, END blocks
>> can execute arbitrary code
> Yeah. In Perl. What part of Perl can access the backend systems without SPI?
> And that it couldn't do at any
Tom Lane wrote:
Peter Eisentraut writes:
On ons, 2010-01-27 at 10:41 -0500, Andrew Dunstan wrote:
I'd like to have an "everything" target that would build "all + html +
contrib".
+10
And maybe an "installcheck-everything" target that would run
installcheck for
On Jan 27, 2010, at 2:38 PM, Tom Lane wrote:
> These proposals sound reasonable to me too, but is "everything" an
> appropriate target name, or is there some other/better convention?
Oooh, more bike-shedding.
make theworld
make toutlemonde
make myday
make lovenotwar
Best,
David
Heikki Linnakangas writes:
> When the set-returning-function feature was written originally, years
> ago, the tuple at a time mode did really work tuple at a time. But it
> had issues and was axed out of the patch before it was committed, to
> keep it simple. The idea was to revisit it at some poi
Peter Eisentraut writes:
> On ons, 2010-01-27 at 10:41 -0500, Andrew Dunstan wrote:
>> I'd like to have an "everything" target that would build "all + html +
>> contrib".
> +10
>> And maybe an "installcheck-everything" target that would run
>> installcheck for src, pl and contrib.
> +100
The
Robert Haas wrote:
Some of the perl patches
have not yet been reviewed either, but I'm a little less concerned
about those because it seems that Andrew is working on those anyway:
still, if anyone feels inclined to volunteer, I believe Andrew has
said he would appreciate another pair of eyes.
On Wed, Jan 27, 2010 at 01:51:47PM -0800, David E. Wheeler wrote:
> On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote:
>
> > Okay. I could change the callback code to ignore calls if
> > proc_exit_inprogress is false. So an abnormal shutdown via exit()
> > wouldn't involve plperl at all. (Alternatively
On Wed, Jan 27, 2010 at 10:41:16AM -0500, Andrew Dunstan wrote:
>
> I'd like to have an "everything" target that would build "all + html
> + contrib".
>
> And maybe an "installcheck-everything" target that would run
> installcheck for src, pl and contrib.
>
> Thoughts?
+1 on both :)
Cheers,
Da
On Tue, Jan 26, 2010 at 1:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 26, 2010 at 12:36 PM, Tom Lane wrote:
>>> But what it *produces* is a string. For comparison, the
>>> SQL-standard-specified array_agg produces arrays, but what it
>>> acts on isn't an array.
>
>> This point i
On Wed, Jan 27, 2010 at 3:42 PM, Robert Haas wrote:
> On Wed, Jan 27, 2010 at 10:17 AM, KaiGai Kohei wrote:
>> (2010/01/27 23:29), Robert Haas wrote:
>>>
>>> 2010/1/27 KaiGai Kohei:
The attached patch is revised one based on the V3 approach.
The only difference from V3 is that it a
On Jan 27, 2010, at 1:53 PM, Robert Haas wrote:
> What exactly do we mean by "system-level actions"? I mean, END blocks
> can execute arbitrary code
Yeah. In Perl. What part of Perl can access the backend systems without SPI?
And that it couldn't do at any other point in runtime?
Best,
Da
On Wed, Jan 27, 2010 at 4:51 PM, David E. Wheeler wrote:
>> Neither of those relate to the actions of perl source code.
>> To address that, instead of calling perl_destruct() to perform a
>> complete destruction I could just execute END blocks and object
>> destructors. That would avoid executing
On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote:
> Okay. I could change the callback code to ignore calls if
> proc_exit_inprogress is false. So an abnormal shutdown via exit()
> wouldn't involve plperl at all. (Alternatively I could use use
> on_proc_exit() instead of atexit() to register the callba
Alvaro Herrera wrote:
Greg Smith wrote:
Alvaro Herrera wrote:
Greg Smith wrote:
We've got pgsql-cluster-hackers to discuss this
particular area.
Huh, is this a new list? It wasn't added to wwwmaster's list of lists,
apparently, right?
The archives are at
http
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Indeed, AFAICS the major *point* of these additions is to allow people
> >> to insert unknown other functionality that is likely to interact
> >> with the rest of the backend; a prospect tha
On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> >> (In particular note that shutdown itself might be fired as an atexit
> >> callback, a move forced on us by exactly the sort of random user code
> >> that
On ons, 2010-01-27 at 09:04 -0800, David Fetter wrote:
> On Wed, Jan 27, 2010 at 04:52:00PM +0200, Peter Eisentraut wrote:
> > On tis, 2010-01-26 at 10:20 -0800, David Fetter wrote:
> > > On Tue, Jan 26, 2010 at 02:21:29PM +, Bruce Momjian wrote:
> > > > Log Message:
> > > > ---
> > > >
On Wed, 27 Jan 2010 22:06:43 +0200
Heikki Linnakangas wrote:
> Ivan Sergio Borgonovo wrote:
> > But then... why do we have all that logic to save the function
> > context if anyway it is more convenient to process everything in
> > one run?
> > It's a pain to save the context just to save a point
On Jan 27, 2010, at 1:00 PM, Joe Conway wrote:
> Implementing true value_per_call is still something on my TODO list, but
> obviously has not risen to a very high priority for me as it has now
> been an embarrassing long time since it was put there. But that said,
> materialize mode has proven extr
We have 20 remaining patches to deal with for the 2010-01 CommitFest.
I've attempted to break down the status of these patches below. The
good news is that almost half of the remaining patches are either
already marked as Ready for Committer, or have already been reviewed
once and will likely be m
--On 27. Januar 2010 15:42:45 -0500 Robert Haas
wrote:
Bernd (or anyone), feel free to take a look in parallel. More eyes
would be helpful...
I've planned to look at this tomorrow when i'm back in office.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Wed, Jan 27, 2010 at 10:17 AM, KaiGai Kohei wrote:
> (2010/01/27 23:29), Robert Haas wrote:
>>
>> 2010/1/27 KaiGai Kohei:
>>>
>>> The attached patch is revised one based on the V3 approach.
>>> The only difference from V3 is that it also applies checks on the
>>> AT_AlterColumnType option, not
On Sun, Jan 17, 2010 at 11:33 AM, Jan Urbański wrote:
> [ detailed review ]
Arie,
Are you planning to submit an updated patch? If so, please do so soon.
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Ivan Sergio Borgonovo wrote:
> But then... why do we have all that logic to save the function
> context if anyway it is more convenient to process everything in one
> run?
> It's a pain to save the context just to save a pointer inside a
> structure, it would be more convenient to just process all
On Tue, Jan 19, 2010 at 4:55 PM, Kurt Harriman wrote:
> I'll submit an updated patch.
We need this patch pretty soon if we're going to include this in 9.0, I think.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On Mon, Jan 25, 2010 at 7:36 AM, Pavel Stehule wrote:
> I hope, so this version is more readable and more clean. I removed
> some not necessary checks.
This still seems overly complicated to me. I spent a few hours today
working up the attached patch. Let me know your thoughts.
...Robert
*** a
On 01/27/2010 09:49 AM, Ivan Sergio Borgonovo wrote:
> On Wed, 27 Jan 2010 17:37:23 +0200
> Heikki Linnakangas wrote:
>
>> Currently, there's no difference in terms of memory needs. The
>> backend always materializes the result of a SRF into a tuplestore
>> anyway, if the function didn't do it it
Peter Eisentraut escribió:
> Everyone,
>
> We could use some help. Anyone's got an idea what could be causing the
> behavior described below?
I wonder if the problem is that you're missing a recheck on the type's
existence after you've grabbed the lock on it, similar to what
shdepLockAndCheckObj
Greg Smith wrote:
> Alvaro Herrera wrote:
> >Greg Smith wrote:
> >
> >>We've got pgsql-cluster-hackers to discuss this
> >>particular area.
> >
> >Huh, is this a new list? It wasn't added to wwwmaster's list of lists,
> >apparently, right?
>
> The archives are at
> http://archives.postgresql.org/
Hi!
I'm happy to facilitate this and get the details in for our
application. Seems like we have lots of things that we could get
students involved with, and of course, we tend to get interesting
projects pitched to us that we haven't thought of before.
I've attended the Mentor Summit after GSoC f
Alvaro Herrera wrote:
Greg Smith wrote:
We've got pgsql-cluster-hackers to discuss this
particular area.
Huh, is this a new list? It wasn't added to wwwmaster's list of lists,
apparently, right?
The archives are at
http://archives.postgresql.org/pgsql-cluster-hackers/ but it's
Greg Smith wrote:
> We've got pgsql-cluster-hackers to discuss this
> particular area.
Huh, is this a new list? It wasn't added to wwwmaster's list of lists,
apparently, right?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Promp
Everyone,
We could use some help. Anyone's got an idea what could be causing the
behavior described below?
On mån, 2010-01-25 at 21:45 +0200, Peter Eisentraut wrote:
> On tis, 2010-01-19 at 01:01 +0900, Hitoshi Harada wrote:
> > * Conflict between transactions
> > I'm not sure if this is relate
On ons, 2010-01-27 at 10:41 -0500, Andrew Dunstan wrote:
> I'd like to have an "everything" target that would build "all + html +
> contrib".
+10
> And maybe an "installcheck-everything" target that would run
> installcheck for src, pl and contrib.
+100
--
Sent via pgsql-hackers mailing li
On Jan 27, 2010, at 10:08 AM, Tom Lane wrote:
> Two examples that I can find in a quick review of our CVS history: perl
> stomping on the process's setlocale state, and perl stomping on the
> stdio state (Windows only).
Are there links to those commits?
Thanks,
David
--
Sent via pgsql-hacker
"David E. Wheeler" writes:
> On Jan 27, 2010, at 9:08 AM, Tom Lane wrote:
>> This is exactly the claim that I have zero confidence in. Quite
>> frankly, the problem with Perl as an extension language is that Perl was
>> never designed to be a subsystem: it feels free to mess around with the
>> en
On Jan 27, 2010, at 9:08 AM, Tom Lane wrote:
> This is exactly the claim that I have zero confidence in. Quite
> frankly, the problem with Perl as an extension language is that Perl was
> never designed to be a subsystem: it feels free to mess around with the
> entire state of the process. We've
On Wed, 27 Jan 2010 17:37:23 +0200
Heikki Linnakangas wrote:
> Currently, there's no difference in terms of memory needs. The
> backend always materializes the result of a SRF into a tuplestore
> anyway, if the function didn't do it itself. There has been
> discussion of optimizing away that mate
On Wed, Jan 27, 2010 at 12:41:28PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Jan 27, 2010 at 12:27:08PM -0500, Tom Lane wrote:
> >> The rule against tabs in SGML files is only a bit of anal
> >> retentivity anyway. I don't think that enforcing it is worth
> >> special hacks that w
David Fetter writes:
> On Wed, Jan 27, 2010 at 12:27:08PM -0500, Tom Lane wrote:
>> The rule against tabs in SGML files is only a bit of anal
>> retentivity anyway. I don't think that enforcing it is worth
>> special hacks that we do not use anywhere else.
> Good point. What other pre-commit ho
On Wed, 2010-01-27 at 12:27 -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Jan 27, 2010 at 04:52:00PM +0200, Peter Eisentraut wrote:
> >> Better write a check in the makefile.
>
> > That assumes that everyone will always actually run the appropriate
> > make before committing, which I
On Wed, Jan 27, 2010 at 12:27:08PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Jan 27, 2010 at 04:52:00PM +0200, Peter Eisentraut wrote:
> >> Better write a check in the makefile.
>
> > That assumes that everyone will always actually run the
> > appropriate make before committing, w
David Fetter writes:
> On Wed, Jan 27, 2010 at 04:52:00PM +0200, Peter Eisentraut wrote:
>> Better write a check in the makefile.
> That assumes that everyone will always actually run the appropriate
> make before committing, which I wouldn't assume, especially for a
> "trivial" patch that's goin
Tom Lane writes:
> [...]
> Lastly, an atexit trigger will still fire during FATAL or PANIC aborts,
> which scares me even more. When the house is already afire, it's
> not prudent to politely let user-written perl code do whatever it wants
> before you get the heck out of there.
Is there a reas
Tim Bunce writes:
> On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
>> (In particular note that shutdown itself might be fired as an atexit
>> callback, a move forced on us by exactly the sort of random user code
>> that you want to add more of. It's not clear whether a Perl-added
>> at
On Wed, Jan 27, 2010 at 04:52:00PM +0200, Peter Eisentraut wrote:
> On tis, 2010-01-26 at 10:20 -0800, David Fetter wrote:
> > On Tue, Jan 26, 2010 at 02:21:29PM +, Bruce Momjian wrote:
> > > Log Message:
> > > ---
> > > Remove tabs in SGML.
> >
> > Can we see about making a commit hoo
f...@redhat.com (Frank Ch. Eigler) writes:
> Tom Lane writes:
>> Lastly, an atexit trigger will still fire during FATAL or PANIC aborts,
>> which scares me even more. When the house is already afire, it's
>> not prudent to politely let user-written perl code do whatever it wants
>> before you get
Andrew Dunstan writes:
> I see I asked the wrong question. Start again.
> What more should be done to make all or some of it acceptable?
I think a "must" is to get rid of the use of atexit(). Possibly an
on_proc_exit callback could be used instead, although I'm not sure how
you'd handle the case
Tom Lane wrote:
But in any case, I don't believe for a moment that profiling is the only
or even the largest use to which people would try to put this.
Well, ISTR there have been requests over the years for event handlers
for (among other things) session shutdown
Ivan Sergio Borgonovo wrote:
Is there a book?
You'll find a basic intro to this area in "PostgreSQL Developer's
Handbook" by Geschwinde and Schonig. You're already past the level of
questions they answer in there though. This whole cstring/text issue
you're asking about, I figured out b
On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
> >> FWIW the atexit scares me to.
>
> > In what way, specifically?
>
> It runs too late, and too unpredictably, during the shutdown sequence.
> (In pa
Magnus Hagander writes:
> 2010/1/27 Martin Atukunda :
>> How about using the psql prompt to convey this information?
> I think the idea is that if you do that, it'll be there all the time,
> potentially "crowding the space".
I had the same reaction as Martin. If you want this info all the time,
Fujii Masao wrote:
> On Wed, Jan 27, 2010 at 8:37 PM, Heikki Linnakangas
> wrote:
>> But SendRqstPtr comes from LogwrtResult.Write, surely that's correct, no?
>
> Right. But the point is that LogwrtResult.Write might indicate 0/FF00
> because it's the last byte + 1 written out. XLogRead() tre
Andrew Dunstan writes:
> Tom Lane wrote:
>> Indeed, AFAICS the major *point* of these additions is to allow people
>> to insert unknown other functionality that is likely to interact
>> with the rest of the backend; a prospect that doesn't make me feel
>> better about it.
> No. The major use case
Tom Lane wrote:
Indeed, AFAICS the major *point* of these additions is to allow people
to insert unknown other functionality that is likely to interact
with the rest of the backend; a prospect that doesn't make me feel
better about it.
No. The major use case we've seen for END blocks is t
Tim Bunce writes:
> On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
>> FWIW the atexit scares me to.
> In what way, specifically?
It runs too late, and too unpredictably, during the shutdown sequence.
(In particular note that shutdown itself might be fired as an atexit
callback, a
with actualised oids
Regards
Pavel Stehule
2010/1/26 David E. Wheeler :
> On Jan 25, 2010, at 6:56 AM, Pavel Stehule wrote:
>
>> actualised patch - the name is string_agg
>
> All looks fine except I'm getting this error during initdb:
>
> creating template1 database in /usr/local/pgsql-devel/data
(2010/01/27 23:29), Robert Haas wrote:
2010/1/27 KaiGai Kohei:
The attached patch is revised one based on the V3 approach.
The only difference from V3 is that it also applies checks on the
AT_AlterColumnType option, not only renameatt().
I think I was clear about what the next step was for thi
Ivan Sergio Borgonovo wrote:
> On Wed, 27 Jan 2010 11:49:46 -0300
> Alvaro Herrera wrote:
>
> > > There are a lot of functions in contrib taking cstring input and
> > > returning cstring output.
> > > Are they just in the same "special" class of [type]in, [type]out
> > > [type]recv... functions?
David Christensen writes:
> That's a good point about forward-compatibility. In that case, I'm
> not sure if "default" is the best name for the human-readable format,
> but I didn't like "human-readable" ;-). I assume that should have an
> explicit spelling, and not just be the format that
2010/1/26 Peter Eisentraut :
> On tis, 2010-01-19 at 01:01 +0900, Hitoshi Harada wrote:
>> I reviewed this patch today.
>
> Thank you for this very thorough and helpful review. Comments below and
> a new patch attached.
>
OK, I confirmed all the issues relevant to the patch were fixed. I'm
not so
I'd like to have an "everything" target that would build "all + html +
contrib".
And maybe an "installcheck-everything" target that would run
installcheck for src, pl and contrib.
Thoughts?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Ivan Sergio Borgonovo wrote:
> I'm more interested in understanding when I should use materialized
> mode.
> eg. I should be more concerned about memory or cpu cycles and what
> should be taken as a reference to consider memory needs "large"?
> If for example I was going to split a large TEXT into
Ivan Sergio Borgonovo wrote:
On Wed, 27 Jan 2010 10:10:01 -0500
Andrew Dunstan wrote:
There are quite a few SRF functions in the code. Look for example
in contrib/hstore/hstore_op.c for some fairly simple examples.
SRFs are quite capable of returning huge resultsets, not just
small ones.
On Wed, 27 Jan 2010 10:10:01 -0500
Andrew Dunstan wrote:
> There are quite a few SRF functions in the code. Look for example
> in contrib/hstore/hstore_op.c for some fairly simple examples.
> SRFs are quite capable of returning huge resultsets, not just
> small ones. Example code for matrerialize
Ivan Sergio Borgonovo wrote:
> There are a lot of functions in contrib taking cstring input and
> returning cstring output.
> Are they just in the same "special" class of [type]in, [type]out
> [type]recv... functions?
If you're looking in contrib subdirectories, perhaps the missing
link here i
On Wed, 27 Jan 2010 11:49:46 -0300
Alvaro Herrera wrote:
> > There are a lot of functions in contrib taking cstring input and
> > returning cstring output.
> > Are they just in the same "special" class of [type]in, [type]out
> > [type]recv... functions?
> Probably, but I didn't check.
Does this
Ivan Sergio Borgonovo wrote:
I just learned there is a "return all row" mode for returning set
functions:
"
There are currently two modes in which a function can return a set
result: value-per-call, or materialize. In value-per-call mode, the
function returns one value each time it is called,
On tis, 2010-01-26 at 10:20 -0800, David Fetter wrote:
> On Tue, Jan 26, 2010 at 02:21:29PM +, Bruce Momjian wrote:
> > Log Message:
> > ---
> > Remove tabs in SGML.
>
> Can we see about making a commit hook for CVS that disallows \t in
> SGML files? The process in git is pretty simpl
Ivan Sergio Borgonovo wrote:
> What's not included in "on SQL level almost everything is text"?
input and output functions always use cstring rather than text. The I/O
functions are normally not used directly at the SQL level.
> There are a lot of functions in contrib taking cstring input and
>
On Wed, 27 Jan 2010 21:41:02 +0800
Craig Ringer wrote:
> I don't code on PostgreSQL's guts, so I'm perhaps not in the best
> position to speak, but:
>
> - Documentation has a cost too, particularly a maintenance cost.
> Outdated docs become misleading or downright false and can be much
> more
1 - 100 of 125 matches
Mail list logo
