Chad Wagner wrote:
> This adds the ability to "prompt" for internal variable input, below
> are examples:
>
> test=# \prompt x
> Enter value for "x": 3
You can do this already approximately so:
\echo -n 'Enter value: '
\set x `read && echo $REPLY`
Maybe one command is better, though.
--
Peter
On 2/8/07, Chad Wagner <[EMAIL PROTECTED]> wrote:
This adds the ability to "prompt" for internal variable input, below are
examples:
In help.c:slashUsage(), the comment says:
/* if you add/remove a line here, change the row count above */
So I guess, the patch should also include a chang
On Thu, Feb 08, 2007 at 10:17:19AM +0100, Peter Eisentraut wrote:
> Chad Wagner wrote:
> > This adds the ability to "prompt" for internal variable input, below
> > are examples:
> >
> > test=# \prompt x
> > Enter value for "x": 3
>
> You can do this already approximately so:
>
> \echo -n 'Enter v
Magnus Hagander wrote:
> That also requires a "reasonable shell", which all platforms don't
> have...
I think doing any sort of reasonable scripting around psql requires a
reasonable shell. Or next someone will suggest implementing loops and
conditionals in psql.
For that matter, I suspect in
On 2/8/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
You can do this already approximately so:
\echo -n 'Enter value: '
\set x `read && echo $REPLY`
Maybe one command is better, though.
Yep, in fact that is more or less something similar that I suggested on
pgsql-sql yesterday. The only
On 2/8/07, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
In help.c:slashUsage(), the comment says:
/* if you add/remove a line here, change the row count above */
So I guess, the patch should also include a change to the line:
output = PageOutput(67, pager); => output = PageOutput(68, pager);
On Wed, Feb 07, 2007 at 09:40:16AM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Tue, Feb 06, 2007 at 11:08:51PM -0500, Tom Lane wrote:
> >> AFAIK the Windows port is simply wrong/insecure on this point --- it's
> >> one of the reasons you'll never see me recommending
Hello,
Could anyone tell me how to use 2GB of shared buffers on Windows? I'm
sorry for attaching large text files and for sending this mail to this
ML.
When I try to start PostgreSQL 8.2.1 on Windows 2003 Server with
shared_buffers=1024MB, I get the following error messages in the Event
Log (with
Tom Lane wrote:
While testing it I realized that there seems to be a nearby bug in
_bt_findsplitloc: it fails to consider the possibility of moving all the
extant items to the left side. It will always return a firstright <=
maxoff. ISTM this would mean that it could choose a bad split if the
i
See here for info that will probably help you:
http://support.microsoft.com/kb/913409
The MS knowledge base is quite a good resource for answers to problems
like this.
Please also note that this is absoutely the wrong list for asking such
questions - this list is *only* for posting patches and
Hello, Andrew-san
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
> See here for info that will probably help you:
>
> http://support.microsoft.com/kb/913409
>
> The MS knowledge base is quite a good resource for answers to
problems
> like this.
>
> Please also note that this is absoutely the wrong lis
On Thu, Feb 08, 2007 at 09:50:26PM +0900, Takayuki Tsunakawa wrote:
> Hello,
>
> Could anyone tell me how to use 2GB of shared buffers on Windows? I'm
> sorry for attaching large text files and for sending this mail to this
> ML.
> When I try to start PostgreSQL 8.2.1 on Windows 2003 Server with
Robert Treat wrote:
> On Wednesday 07 February 2007 23:35, Bruce Momjian wrote:
> > Robert Treat wrote:
> > > Can someone apply Jim's patch at least to HEAD and REL8_2_STABLE? We
> > > recently got a report of a broken link on the website due to this; seems
> > > it is still broken...
> >
> > OK,
Magnus Hagander <[EMAIL PROTECTED]> writes:
> If we just didn't add the serial number at the end, then it would be
> impossible to create a shared memory segment for the same port again.
> That protects the port and not the datadir. But what if we change the
> name of the shared memory segment to b
Patch applied. Thanks.
---
Simon Riggs wrote:
> On Wed, 2007-01-17 at 16:15 +, Simon Riggs wrote:
> > On Wed, 2007-01-17 at 10:05 -0500, Merlin Moncure wrote:
> > > On 12/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
Patch applied. Thanks.
---
Magnus Hagander wrote:
> Attached is an updated patch for the win32/visualc++ specific parts of
> my previous patch, not included in the parts applied by Alvaro.
>
> For win32 in general, this m
Patch applied. Thanks.
---
Teodor Sigaev wrote:
> 1) mvcc.sgml.patch
> Update comments about installation of DocBook on FreeBSD. DocBook v4.2 is
> present in ports now.
>
> 2) docguide.sgml.patch
> Table of compatibili
Patch applied. Thanks. I did not backpatch this to 8.2.X. If I
should, let me know.
---
[EMAIL PROTECTED] wrote:
> This patch fixes shared_preload_libraries on Windows hosts. It forces
> ach backend to re-load all share
> Patch applied. Thanks. I did not backpatch this to 8.2.X. If I
> should, let me know.
Thanks Bruce - this bug will prevent plugins (like the PL/pgSQL debugger,
profiler, and tracer) from working on Windows hosts, so I think it would be
useful to backpatch to 8.2.
-- Korry
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Heikki Linnakangas wrote:
> >> Tom Lane wrote:
> >>> BTW, I don't care much for the terminology "phantom cid" ... there's
> >>> nothing particularly "phantom" about them, seeing they get onto disk.
> >>> Can anyone think of a better n
Heikki Linnakangas wrote:
> Here's an updated version of the phantom command ids patch.
>
> I found one more subtle safety issue. The array and hash table for
> phantom command ids is dynamically grown when HeapTupleHeaderSetCmax is
> called. Unfortunately, since HeapTupleHeaderSetCmax is used i
Bruce Momjian wrote:
> Heikki Linnakangas wrote:
> > Here's an updated version of the phantom command ids patch.
> >
> > I found one more subtle safety issue. The array and hash table for
> > phantom command ids is dynamically grown when HeapTupleHeaderSetCmax is
> > called. Unfortunately, since
Bruce Momjian wrote:
Heikki, I found something odd in your patch. You had an extra
parentheses at the end of the line in the orginal and new version of the
patch (attached). I removed it before applying, but I just wanted to
confirm this was OK.
Looking at the CVS history, it looks like Tom c
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Heikki, I found something odd in your patch. You had an extra
> > parentheses at the end of the line in the orginal and new version of the
> > patch (attached). I removed it before applying, but I just wanted to
> > confirm this was OK.
>
> Lo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Heikki, I found something odd in your patch. You had an extra
> parentheses at the end of the line in the orginal and new version of the
> patch (attached). I removed it before applying, but I just wanted to
> confirm this was OK.
Please do not apply t
Alvaro Herrera wrote:
> > > Per Tom's suggestion, I replaced the function cache code in fmgr.c and
> > > similar code in plperl.c, pltcl.c, plpgsql/pl_comp.c and plpython.c to
> > > use xmin+tid instead of xmin+cmin for the up-to-dateness check. I don't
> > > have any tcl, perl or python test ca
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Heikki, I found something odd in your patch. You had an extra
> > parentheses at the end of the line in the orginal and new version of the
> > patch (attached). I removed it before applying, but I just wanted to
> > confirm this was
[EMAIL PROTECTED] wrote:
> > Patch applied. Thanks. I did not backpatch this to 8.2.X. If I
> > should, let me know.
>
>
>
> Thanks Bruce - this bug will prevent plugins (like the PL/pgSQL
> debugger, profiler, and tracer) from working on Windows hosts, so I
> think it would be useful to back
Patch applied. Thanks.
I have not backpatched it to 8.2.X because I am unclear of the risk
involved. Suggestions?
---
Pavel Stehule wrote:
> >"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > > This patch correct bug, when
Should we revisit xpath_array() for 8.3, or is this all in core now?
---
Tom Lane wrote:
> "Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> > Here is the patch for contrib/xml2 (attached), that:
> > - renames xml_valid()
I assume we no longer need this stats patch from May of 2006.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Have we seen any such failures since the first day they appeared?
> >
> > agouti blew
> [EMAIL PROTECTED] wrote:
> > > Patch applied. Thanks. I did not backpatch this to 8.2.X. If I
> > > should, let me know.
> >
> >
> >
> > Thanks Bruce - this bug will prevent plugins (like the PL/pgSQL
> > debugger, profiler, and tracer) from working on Windows hosts, so I
> > think it would
Patch applied. Thanks.
I have not backpatched it to 8.2.X because I am unclear of the risk
involved. Suggestions?
It's bug in 8.2. I don't know about any risks for 8.2
Pavel
---
Pavel Stehule wrote:
> >"Pavel Steh
Bruce Momjian wrote:
> Should we revisit xpath_array() for 8.3, or is this all in core now?
Not yet, but we are currently discussing how.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9: In versions belo
Pavel Stehule wrote:
>
> >Patch applied. Thanks.
> >
> >I have not backpatched it to 8.2.X because I am unclear of the risk
> >involved. Suggestions?
>
> It's bug in 8.2. I don't know about any risks for 8.2
OK, I have backpatched it to 8.2.X.
-
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> If we just didn't add the serial number at the end, then it would be
>> impossible to create a shared memory segment for the same port again.
>> That protects the port and not the datadir. But what if we change the
>> name of the shar
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> If we just didn't add the serial number at the end, then it would be
>>> impossible to create a shared memory segment for the same port again.
>>> That protects the port and not the data
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Magnus Hagander <[EMAIL PROTECTED]> writes:
If we just didn't add the serial number at the end, then it would be
impossible to create a shared memory segment for the same port again.
That protects th
Would someone review this. It is in the patches_hold queue:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Andrew Dunstan wrote:
>
> I think it has to wait to 8.3. It's a complete mess that was submitted
Has it been resubmitted with issues attended to? If it has, I missed it.
If not, why should someone else waste time on something so broken that
it produced a stringified perl hashref on output? It should never have
gone back in the queue IMNSHO.
cheers
andrew
Bruce Momjian wrote:
Would s
Anyways, here is the patch again with the pager output changed from 67 to
69. Feel free to use it or ignore it, I still think it is a useful patch
and doesn't necessary imply that users will want looping next (although, I
would like to do anonymous PL/pgSQL chunks ;). I just understand how usefu
Andrew Dunstan wrote:
>
> Has it been resubmitted with issues attended to? If it has, I missed it.
> If not, why should someone else waste time on something so broken that
> it produced a stringified perl hashref on output? It should never have
> gone back in the queue IMNSHO.
Fine, removed.
This patch has been rejected based on comments just made by Andrew
Dunstan. If the author wants to revisit that, please reply and we can
discuss the issues.
---
Andrew Dunstan wrote:
>
>
> I wrote:
> > Pavel Stehule wrote
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Dh
Where are we on this feature?
---
Bernd Helmle wrote:
> --On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>
> > Bernd Helmle <[EMAIL PROTECTED]> writes:
> >> [ latest views patch ]
> >
> >
OK, where are we on this patch?
---
Pavel Stehule wrote:
>
>
> >
> >"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > >> This patch doesn't seem to cope with cases where the supplied tuple has
> > >> the wrong number of colu
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I found one more subtle safety issue. The array and hash table for
> phantom command ids is dynamically grown when HeapTupleHeaderSetCmax is
> called. Unfortunately, since HeapTupleHeaderSetCmax is used inside a
> critical sections, running out of
Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
I think the SELECT query is short on quoting an
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > It will be applied as soon as one of the PostgreSQL committers reviews
> > and approves it.
>
> I think
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Vi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think we discussed replacing the current sequence representation with
> a single relation that would contain all sequences in the database, so
> that you could do "select * from pg_sequence" and get all the values in
> one go. The idea was considered
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I think we discussed replacing the current sequence representation with
> > a single relation that would contain all sequences in the database, so
> > that you could do "select * from pg_sequence" and get all the values in
> > one go.
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> That also requires a "reasonable shell", which all platforms don't
>> have...
>
> I think doing any sort of reasonable scripting around psql requires a
> reasonable shell. Or next someone will suggest implementing loops and
> conditionals in p
Joshua D. Drake wrote:
> Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> >> That also requires a "reasonable shell", which all platforms don't
> >> have...
> >
> > I think doing any sort of reasonable scripting around psql requires a
> > reasonable shell. Or next someone will suggest implem
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>> Peter Eisentraut wrote:
>>> Magnus Hagander wrote:
That also requires a "reasonable shell", which all platforms don't
have...
>>> I think doing any sort of reasonable scripting around psql requires a
>>> reasonable shell. Or next someone
Is this patch ready for application?
---
Jeremy Drake wrote:
> This is the latest version of the large object regression test I have been
> working on. Note that a prerequisite for this version of the test is the
> patch I
Bruce Momjian wrote:
>
> Is this patch ready for application?
I think the sed usage would cause problems for the VC++ builds. It
would be good if the files could be reformulated as files in the input,
output or data directories; pg_regress would take care to generate the
files as needed.
>
On Thu, 8 Feb 2007, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Is this patch ready for application?
It already has been.
>
> I think the sed usage would cause problems for the VC++ builds. It
> would be good if the files could be reformulated as files in the input,
> output or data di
Jeremy Drake wrote:
> On Thu, 8 Feb 2007, Alvaro Herrera wrote:
>
> > Bruce Momjian wrote:
> > >
> > > Is this patch ready for application?
>
> It already has been.
Ah, I see it now. Strange I missed seeing that. Thanks.
-
On Wed, 7 Feb 2007, Jeremy Drake wrote:
> Here is a patch to add these functions to core. Please take a look and
> let me know what you think. I had to jump through a bit of a hoop to
> avoid opr_sanity test from breaking, may not have done that right.
>
> Also, this patch allows regexp_replace
On Thu, 2007-02-08 at 19:22 -0800, Jeremy Drake wrote:
> I have added documentation for the functions in this patch. At this point
> I am ready to submit this patch for the review and application process.
> Please let me know if you find any issues with it.
Barring any objections, I'll review and
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's an updated version of the phantom command ids patch.
Applied with some revisions (notably, renaming 'em to "combo" command IDs).
regards, tom lane
---(end of broadcast)
Neil Conway wrote:
> BTW, unless the patch is truly large, leaving the patch uncompressed
> makes it easier to eyeball it without leaving my mail client. That's
> just personal preference, though...
FWIW, I just do a "| zcat | less", which shows it uncompressed. No big
deal. I don't know if Evo
Alvaro Herrera wrote:
> Neil Conway wrote:
>
> > BTW, unless the patch is truly large, leaving the patch uncompressed
> > makes it easier to eyeball it without leaving my mail client. That's
> > just personal preference, though...
>
> FWIW, I just do a "| zcat | less", which shows it uncompressed
Full_page_compress is not intended to use with PITR slave, but for the
case to keep both online backup and archive log for archive recovery,
which is very popular PostgreSQL operation now.
I've just posted my evaluation for the patch as a reply for another
thread of the same proposal (sorry, I cre
Euler Taveira de Oliveira wrote:
> Jorge Godoy wrote:
>
> > > In the pt_BR locale, the thousand separator is "". So it should return
> >
> > The thousands separator in pt_BR is ".".
> >
> Oh, good catch. There is so much hack in my glibc. :-)
I researched this thread:
http://archives
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ultimately, the result was that glibc was wrong in its locale settings,
> and there was a suggestion to use defaults only when using the C locale.
> However, I am worried there are too many locales in the field that only
> define some of the locale settin
As discussed earlier, using POSIX shared memory can solve a few issues,
On Mac OS X and other BSD's, the default System V shared memory
limits are often very low and require adjustment for acceptable
performance. Particularly, when Postgres is included as part of
larger end-user friendly sof
68 matches
Mail list logo
