Followup --- something weird is going on. I am seeing _random_ failures
of the regression tests here in that same place, and the build farm
seems to fail in the same place, but with different row counts.
I am heading to bed but when I wake up, if it still an issue, I will
revert the patch.
Tom Lane wrote:
> "FAST PostgreSQL" <[EMAIL PROTECTED]> writes:
> > On Fri, 16 Feb 2007 11:50, Tom Lane wrote:
> >> Why not output the data in COPY format instead?
>
> > Yeah, that was my initial idea too... But because the TODO item clearly
> > mentions INSERT, I thought maybe there was some ver
I am seeing buildfarm failures from the new regression tests added by
this patch. Would someone research why this is happening?
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
---
bruce wrote:
>
> Patch applied.
I have tested this patch but it generates regression failures.
There was some code drift, so I am attaching an updated version of the
patch, and the regression diffs. The 'four' column is an 'int4' so my
guess is that somehow the wrong aggregate is being called.
"FAST PostgreSQL" <[EMAIL PROTECTED]> writes:
> On Fri, 16 Feb 2007 11:50, Tom Lane wrote:
>> Why not output the data in COPY format instead?
> Yeah, that was my initial idea too... But because the TODO item clearly
> mentions INSERT, I thought maybe there was some very specific reason for the
>
Patch applied. Thanks.
---
Brendan Jurd wrote:
> The attached patch implements my proposal to extend support for the
> ISO week date calendar.
>
> I have added two new format fields for use with to_char, to_date and
> to_
On Fri, 16 Feb 2007 11:50, Tom Lane wrote:
> "FAST PostgreSQL" <[EMAIL PROTECTED]> writes:
> > The second variable is of interest. We need to specify a table in the
> > insert command. My preferred option is for the user to give one and he
> > can create it if and when he wants to. The alternative
Patch applied --- SSL improvements:
o read global SSL configuration file
o add GUC "ssl_ciphers" to control allowed ciphers
o add libpq environment variable PGSSLKEY to control SSL
hardware keys
I adjusted the documentation wording and some of the single-letter
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
I've obviously misunderstood the scope of the TODO because it appears
that an INSERT into pg_type at creation time for compound types that
looks something like the below would do it. What have I missed?
There are a couple of i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (c) Can't you remove the output-dbname argument you added to InitPostgres?
> (I'm not sure if this last comment is related to this particular patch
> or a gripe about the InitPostgres change in the autovac patch?)
No, I was thinking
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > This little patch removes the dbname argument to InitPostgres in the
> > bootstrap mode. It also cleans a bit of fallout: initdb uselessly
> > passing an unused database name, postmaster starting a dummy process,
> > and removes the
On Thu, Feb 15, 2007 at 07:35:46PM -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > I've obviously misunderstood the scope of the TODO because it appears
> > that an INSERT into pg_type at creation time for compound types that
> > looks something like the below would do it. Wh
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This little patch removes the dbname argument to InitPostgres in the
> bootstrap mode. It also cleans a bit of fallout: initdb uselessly
> passing an unused database name, postmaster starting a dummy process,
> and removes the -y option to the bootstrap
"FAST PostgreSQL" <[EMAIL PROTECTED]> writes:
> The second variable is of interest. We need to specify a table in the insert
> command. My preferred option is for the user to give one and he can create it
> if and when he wants to. The alternative is we decide the table name and make
> initdb to
David Fetter <[EMAIL PROTECTED]> writes:
> I've obviously misunderstood the scope of the TODO because it appears
> that an INSERT into pg_type at creation time for compound types that
> looks something like the below would do it. What have I missed?
There are a couple of issues. One is that we p
This little patch removes the dbname argument to InitPostgres in the
bootstrap mode. It also cleans a bit of fallout: initdb uselessly
passing an unused database name, postmaster starting a dummy process,
and removes the -y option to the bootstrap process, which is
undocumented and useless.
Unles
Hi,
I've been working on the following TODO item and attached is an initial patch.
(It is only partial and not yet completely functional)
"Allow server log information to be output as INSERT statements
This would allow server log information to be easily loaded into a database for
analysis. "
On Thu, 15 Feb 2007, Alvaro Herrera wrote:
> Jeremy Drake wrote:
>
> > The functions added are:
> > * regexp_split(str text, pattern text) RETURNS SETOF text
> > regexp_split(str text, pattern text, flags text) RETURNS SETOF text
> >returns each section of the string delimited by the pattern
On Thu, Feb 15, 2007 at 10:57:45AM +0100, Peter Eisentraut wrote:
> Jeremy Drake wrote:
> > # With a set-returning function, it is possible to add a LIMIT
> > clause, to prevent splitting up more of the string than is
> > necessary.
>
> You can also add such functionality to a function in form of
On Thu, Feb 15, 2007 at 10:37:26AM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > so that you would have the position for each match, automatically. Is
> > this information available in the regex code?
>
> Certainly, that's where we got the text snippets from to begin wit
Alvaro Herrera wrote:
> On the other hand, I don't think it's impossible to have matches that
> start earlier than others in the string, but are actually found later
> (say, because they are a parentized expression that ends later). So
> giving the starting positions allows one to know where are t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think a warning comment is warranted here -- will include it when I
> commit the patch.
I was thinking the same, but didn't want to create a merge problem for
you. Maybe "Individual lock IDs end here" or some such?
regards, t
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > so that you would have the position for each match, automatically. Is
> > this information available in the regex code?
>
> Certainly, that's where we got the text snippets from to begin with.
> However, I'm not sure that this is im
Tom Lane wrote:
I forgot to comment:
> This part is very seriously broken:
>
> diff -c -p -r1.33 lwlock.h
> *** src/include/storage/lwlock.h 5 Jan 2007 22:19:58 - 1.33
> --- src/include/storage/lwlock.h 13 Feb 2007 16:58:41 -
> *** typedef enum LWLockId
> ***
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> so that you would have the position for each match, automatically. Is
> this information available in the regex code?
Certainly, that's where we got the text snippets from to begin with.
However, I'm not sure that this is important enough to justify a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Jeremy Drake wrote:
>> # My experience with the array code leads me to believe that building
>> up an array is an expensive proposition. I know I could code it
>> smarter so that the array is only constructed in the end.
> You can make any code arbit
I've fixed all other problems according to suggestions, including adding
a SignalSomeChildren(int signal, bool only_autovac) function to
postmaster so that it can shut autovac workers down in case of smart
shutdown.
Tom Lane wrote:
> Making InitPostgres's call API vary depending on
> IsAutoVacuum
Jeremy Drake wrote:
> The functions added are:
> * regexp_split(str text, pattern text) RETURNS SETOF text
> regexp_split(str text, pattern text, flags text) RETURNS SETOF text
>returns each section of the string delimited by the pattern.
> * regexp_matches(str text, pattern text) RETURNS te
Hi!
I took a stab at implementing MOVE support for cursors in PL/pgsql,
because I wanted it for a project. Attached patch *seems* to work. But..
Given that this is my first venture into touching bison/flex files, I
may be completely off-target in how it's done.
Could somebody take a look at it an
Jeremy Drake wrote:
> regexp_matches uses a text[] for the match groups. If you specify
> the global flag, it could return multiple matches. Couple this with
> the requested feature of pre- and postmatch returns (with its own
> flag) and the return would turn into some sort of nasty array of
> tu
On Thu, 15 Feb 2007, Peter Eisentraut wrote:
> Neil Conway wrote:
> > On Wed, 2007-02-14 at 16:49 -0800, Jeremy Drake wrote:
> > > What was the status of this? Was there anything else I needed to
> > > do with this patch, or is it ready to be applied? Let me know if
> > > there is anything else
Neil Conway wrote:
> On Wed, 2007-02-14 at 16:49 -0800, Jeremy Drake wrote:
> > What was the status of this? Was there anything else I needed to
> > do with this patch, or is it ready to be applied? Let me know if
> > there is anything else I need to do on this...
>
> Will do -- I'm planning to a
32 matches
Mail list logo
