Robert Haas wrote:
> With respect to tab completion, ALTER TABLESPACE x currently completes
> with only "OWNER TO" or "RENAME TO"; we need to add "SET" to that
> list. My bad.
Ok, I'll go for it.
I see non-tab-completion parts are too late for 9.0.
Regards,
---
Takahiro Itagaki
NTT Open Sourc
2010/1/25 Robert Haas :
> On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler
> wrote:
>> On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
>>> xmlagg -> concatenates values to form xml datum
>>> array_agg -> concatenates values to form array datum
>>> ??? -> concatenates values to form string d
2010/1/25 Magnus Hagander :
> 2010/1/25 Josh Berkus :
>> On 1/25/10 7:47 AM, Pavel Stehule wrote:
>>> Hello
>>>
>>> I can't to create module on pgfoundry. It is probably access denied
>>> problem. Can somebody help me with this?
>>>
>>> [pa...@nemesis pstcoll]$ cvs -d
>>> :ext:ok...@cvs.pgfoundry.
On sön, 2010-01-24 at 21:56 +0200, Heikki Linnakangas wrote:
> >> "PREPARE TRANSACTION is not intended for use in applications or in
> >> interactive sessions. It's purpose is to allow an external transaction
> >> manager to perform atomic global transactions across multiple databases
> >> or other
2010/1/25 David E. Wheeler :
> On Jan 25, 2010, at 6:12 AM, Pavel Stehule wrote:
>
>> I am not happy, I thing so we do bigger chaos then it is. But it
>> hasn't progress. So I agree with name string_agg. In this case isn't a
>> problem rename this function if somebody would.
>
> Could you not use C
On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
> >> +1 for removing default_do_language, too.
>
> > +1 for removing default_do_language OR adding default_language.
>
> > I prefer a hard-wired default of PLpgSQL,
On mån, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
> >> +1 for removing default_do_language, too.
>
> > +1 for removing default_do_language OR adding default_language.
>
> > I prefer a hard-wired default of PLpgSQL,
On Mon, Jan 25, 2010 at 08:26:14PM -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
> >> +1 for removing default_do_language, too.
>
> > +1 for removing default_do_language OR adding default_language.
>
> > I prefer a hard-wired default of PL
On Mon, 2010-01-25 at 20:26 -0500, Tom Lane wrote:
> So it seems everyone is okay with the latter? (Remove
> default_do_language in place of a hard-wired default of "plpgsql",
> don't change CREATE FUNCTION's behavior.)
+1
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pg
On Mon, Jan 25, 2010 at 05:29:54PM -0500, Bruce Momjian wrote:
> Josh Berkus wrote:
> > On 1/25/10 1:24 PM, Magnus Hagander wrote:
> > > 2010/1/25 Peter Eisentraut :
> > >> When editing pg_hba.conf, I often instinctively try to use tabs, only to
> > >> be slightly annoyed because that barely doesn'
On Mon, Jan 25, 2010 at 6:31 PM, Tom Lane wrote:
> Greg Stark writes:
>> Given this thread on pgsql-general I wonder if we should have
>> something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
>> client socket is still open.
>
> ... and do what? If so, why?
Hm, an interesting questio
On Tue, Jan 26, 2010 at 9:08 AM, Simon Riggs wrote:
> Just committed a fix: the server no longer requests 01.history
> at start of archive recovery.
Good.
And I think that writeTimeLineHistory() should also skip the request
of 01.history. Here is the patch to do so. Comments?
Re
Tom Lane wrote:
writes:
Would it be possible and worthwhile to add functionality to pg_restore so
that with one switch triggers/indexes/constraints could be ignored, and
with another switch only triggers/indexes/constraints would be restored?
You should probably go back and look at
Simon Riggs writes:
> On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
>> +1 for removing default_do_language, too.
> +1 for removing default_do_language OR adding default_language.
> I prefer a hard-wired default of PLpgSQL, so a missing language
> statement on a DO block is always interpr
Leonardo F writes:
>> Rule it out. Note you should be looking at pg_am.amcanorder, not
>> hardwiring knowledge of particular index types.
> I can look at pg_am.amcanorder, but I would still need the ScanKey to be used
> by tuplesort; and I can't find any other way of doing it than calling
> _b
(2010/01/26 1:11), Bernd Helmle wrote:
>
>
> --On 25. Januar 2010 11:39:21 +0900 KaiGai Kohei
> wrote:
>
>> (echo "CREATE TABLE t (a int);"
>> for i in `seq 0 9`; do
>> echo "CREATE TABLE s$i (b int) INHERITS(t);"
>> for j in `seq 0 9`; do
>> echo "CREATE TABLE v$i$j (c int) INHERITS(s$i);"
>>
Tom Lane wrote:
Maybe I'm missing something, but I thought pg_standby would be mostly
dead once SR hits the streets. Is it worth spending lots of time on?
I have to do the work I outlined regardless, to support installs on
earlier versions (luckily there's few backport issues for this code
On 1/25/10 4:09 PM, Tom Lane wrote:
> Greg Smith writes:
>> [ Greg and Selena discuss filing some rough edges off pg_standby ]
>
> Maybe I'm missing something, but I thought pg_standby would be mostly
> dead once SR hits the streets. Is it worth spending lots of time on?
>
> The ideas all sound
Greg Smith writes:
> [ Greg and Selena discuss filing some rough edges off pg_standby ]
Maybe I'm missing something, but I thought pg_standby would be mostly
dead once SR hits the streets. Is it worth spending lots of time on?
The ideas all sound good, I'm just wondering if it's useful effort
a
On Mon, 2010-01-25 at 16:34 -0500, Greg Smith wrote:
> Josh Berkus wrote:
> > We discussed this issue at LCA where I encountered these bogus error
> > messages when I was doing the demo of HS. I consider Selena's patch to
> > be a bug-fix for beta of 9.0, not a feature. Currently the database
> >
writes:
> Would it be possible and worthwhile to add functionality to pg_restore so
> that with one switch triggers/indexes/constraints could be ignored, and
> with another switch only triggers/indexes/constraints would be restored?
You should probably go back and look at the archives from the la
(2010/01/26 6:30), Magnus Hagander wrote:
> 2010/1/25 KaiGai Kohei:
>> (2010/01/24 23:29), Magnus Hagander wrote:
>>> There is one more option here - use OpenSSL if available. It has
>>> functions for secure random number generations
>>> (http://www.openssl.org/docs/crypto/RAND_bytes.html). That s
Le 26/01/2010 00:04, Joe Conway a écrit :
> I'm reviewing the patch posted here:
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01579.php
> for this commitfest item:
> https://commitfest.postgresql.org/action/patch_view?id=259
>
First, thanks for reviewing my patch.
> Patch attach
I'm reviewing the patch posted here:
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01579.php
for this commitfest item:
https://commitfest.postgresql.org/action/patch_view?id=259
Patch attached - a few minor changes:
-
1) Updated to apply cleanly ag
Ivan Sergio Borgonovo wrote:
The README files might be a good place to start, then browse code.
> Is there any part of the code from where I could learn about:
> - memory allocation for both cstring and text
src/backend/utils/mmgr/README
> - example of returning text (especially if size of
Josh Berkus wrote:
> On 1/25/10 1:24 PM, Magnus Hagander wrote:
> > 2010/1/25 Peter Eisentraut :
> >> When editing pg_hba.conf, I often instinctively try to use tabs, only to
> >> be slightly annoyed because that barely doesn't work out relative to the
> >> default entries, because those are aligne
Selena Deckelmann wrote:
I can scan through the code tonight and look for other cases where
this might be an issue. The main thing I'm looking for is to
distinguish between harmful and non-harmful errors.
Where I think this is going toward is where every line that comes out of
this program
Hi!
On Mon, Jan 25, 2010 at 1:34 PM, Greg Smith wrote:
> Josh Berkus wrote:
>>
>> We discussed this issue at LCA where I encountered these bogus error
>> messages when I was doing the demo of HS. I consider Selena's patch to
>> be a bug-fix for beta of 9.0, not a feature. Currently the database
On Mon, Jan 25, 2010 at 12:01 PM, Greg Smith wrote:
> I think it's completely reasonable to say that someone could organize
> pgsql-rrreviewers (as an initial working area, maybe another list
> eventually) for periodic ReviewFest during periods where those patches won't
> be considered for commit,
Greg Sabino Mullane recently shared a script to split schema-only dump
files into a table creation file and a trigger/index/constraint file, for
restore performance reasons.
(http://blog.endpoint.com/2010/01/splitting-postgres-pgdump-into-pre-and.html)
Would it be possible and worthwhile to add fu
On 1/25/10 1:24 PM, Magnus Hagander wrote:
> 2010/1/25 Peter Eisentraut :
>> When editing pg_hba.conf, I often instinctively try to use tabs, only to
>> be slightly annoyed because that barely doesn't work out relative to the
>> default entries, because those are aligned at column 0, 8, 20, 32, 54:
Josh Berkus wrote:
We discussed this issue at LCA where I encountered these bogus error
messages when I was doing the demo of HS. I consider Selena's patch to
be a bug-fix for beta of 9.0, not a feature. Currently the database
reports a lot of false error messages when running in standby mode,
2010/1/25 KaiGai Kohei :
> (2010/01/24 23:29), Magnus Hagander wrote:
>> There is one more option here - use OpenSSL if available. It has
>> functions for secure random number generations
>> (http://www.openssl.org/docs/crypto/RAND_bytes.html). That seems easy
>> enough when OpenSSL is available.
2010/1/25 Peter Eisentraut :
> When editing pg_hba.conf, I often instinctively try to use tabs, only to
> be slightly annoyed because that barely doesn't work out relative to the
> default entries, because those are aligned at column 0, 8, 20, 32, 54:
>
> # TYPE DATABASE USER CIDR-ADDRES
"Kevin Grittner" writes:
> Leonardo F wrote:
>> New version of the patch, let me know if I can fix/change something
>> else.
> All issues addressed, with one tiny nit-pick -- the get_bit and
> set_bit methods are not part of the SQL standard. I took the liberty
> of removing "SQL-standard" from t
Joshua D. Drake wrote:
My suggestion would be to start a new thread entirely.
And mine would be to drop this whole topic altogether until after the
CommitFest is over, and instead focus on the replication features
already committed that need work before beta can even start. Only
reason I
When editing pg_hba.conf, I often instinctively try to use tabs, only to
be slightly annoyed because that barely doesn't work out relative to the
default entries, because those are aligned at column 0, 8, 20, 32, 54:
# TYPE DATABASEUSERCIDR-ADDRESS METHOD
hostall
On Mon, Jan 25, 2010 at 2:27 PM, David E. Wheeler wrote:
> On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
>> xmlagg -> concatenates values to form xml datum
>> array_agg -> concatenates values to form array datum
>> ??? -> concatenates values to form string datum
>
> concat_agg().
I like th
On Fri, Jan 15, 2010 at 04:02:02AM +, Tim Bunce wrote:
> This is the final plperl patch in the series from me.
>
> Changes in this patch:
>
> - Moved internal functions out of main:: namespace
> into PostgreSQL::InServer and PostgreSQL::InServer::safe
>
> - Restructured Safe compartment
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.
> * in namespace.c
> I didn't see why this file has been changed.
> case 0:
>
I'm having a hard time trying to understand how everything should be
done in C extensions.
Now I'm trying to understand how and when I should accept/return
cstring vs text and if and how I should take care of any encoding.
I'm trying to output the content of a tsvector as a set of record
pos, wei
"Kevin Grittner" writes:
> "Kevin Grittner" wrote:
>> Tom Lane wrote:
>>> Did you happen to notice anything about pg_dump's memory
>>> consumption?
> I took a closer look, and there's some bad news, I think. The above
> numbers were from the ends of the range. I've gone back over and
> found
On Mon, Jan 25, 2010 at 11:09:12AM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >
> >FYI I've an updated patch ready but I'll wait till the commitfest has
> >got 'closer' as there's a fair chance a further update will be needed
> >anyway to make a patch that applies cleanly.
>
> I want to
On Jan 25, 2010, at 6:12 AM, Pavel Stehule wrote:
> I am not happy, I thing so we do bigger chaos then it is. But it
> hasn't progress. So I agree with name string_agg. In this case isn't a
> problem rename this function if somebody would.
Could you not use CREATE AGGREGATE to create an alias nam
On Jan 25, 2010, at 2:09 AM, Peter Eisentraut wrote:
> xmlagg -> concatenates values to form xml datum
> array_agg -> concatenates values to form array datum
> ??? -> concatenates values to form string datum
concat_agg().
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Michael Meskes írta:
> On Mon, Jan 25, 2010 at 07:52:05PM +0100, Boszormenyi Zoltan wrote:
>
>> But considering all the above, we might not need the new
>> compat_informix/struct.pgc regression test. I think it was tested
>> already in e.g. preproc/array_of_struct.pgc and preproc/type.pgc
>> and
On Wed, 2010-01-20 at 19:32 -0700, James William Pye wrote:
> Apologies ahead of time for the lack pretty graphs. =)
>
> I used two different builds/installations of PG to test as the PL names
> conflict. Both were compiled with the following CFLAGS(pg_config output):
>
> -O2 -Wall -Wmissing-p
"Kevin Grittner" wrote:
> Tom Lane wrote:
>
>> Did you happen to notice anything about pg_dump's memory
>> consumption?
>
> Not directly, but I was running 'vmstat 1' throughout. Cache
> space dropped about 2.1 GB while it was running and popped back up
> to the previous level at the end.
On Mon, Jan 25, 2010 at 07:52:05PM +0100, Boszormenyi Zoltan wrote:
> But considering all the above, we might not need the new
> compat_informix/struct.pgc regression test. I think it was tested
> already in e.g. preproc/array_of_struct.pgc and preproc/type.pgc
> and the new feature (if accepted) i
On Mon, 2010-01-25 at 10:50 -0800, Josh Berkus wrote:
> All,
>
> Please rename this thread. I think that several people to whom it's
> relevant aren't replying to it because of the deceptive name. Thanks.
>
Except that it is. This thread was about whether or not, Mammoth would
be considered to
On 1/23/10 5:00 PM, Brook Milligan wrote:
> It seems that src/Makefile.shlib has special cases for several
> directories that build loadable modules rather than shared libraries.
> The contrib/adminpack is one of the special cases, but none of the
> other contrib directories are. As a result, they
Michael Meskes írta:
> On Sun, Jan 24, 2010 at 07:25:24PM +0100, Boszormenyi Zoltan wrote:
>
>> The problem that popped up first was that adjust_informix()
>> didn't properly deal with structs, remember? I tried some
>>
>
> Yes, that's what made me wondering.
>
>
>> i.e. IIRC in some cas
All,
Please rename this thread. I think that several people to whom it's
relevant aren't replying to it because of the deceptive name. Thanks.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
> A group of people who have an interest in using Hot Standby, as
> advertised on postgresql.org and Weekly News.
There are pg users who won't be using HS/SR? ;-)
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
>> My problem with this whole idea is that it seems to be very MySQL-specific.
>> Why aren't we providing help for users migrating from Oracle, Sybase,
>> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
>> turn all those on by default, we'll have a pretty horrible banne
Tom Lane wrote:
> Did you happen to notice anything about pg_dump's memory
> consumption?
Not directly, but I was running 'vmstat 1' throughout. Cache space
dropped about 2.1 GB while it was running and popped back up to the
previous level at the end.
-Kevin
--
Sent via pgsql-hackers mail
2010/1/25 Josh Berkus :
> On 1/25/10 7:47 AM, Pavel Stehule wrote:
>> Hello
>>
>> I can't to create module on pgfoundry. It is probably access denied
>> problem. Can somebody help me with this?
>>
>> [pa...@nemesis pstcoll]$ cvs -d
>> :ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pst
Robert Haas wrote:
> Issues that are discussed and resolved in that forum will very
> possibly get brought up again on -hackers and reach a different
> conclusion the second time around. Now if people are OK with
> that, maybe it's OK
I would expect that. Heck, people get that to some degree
On 1/25/10 7:47 AM, Pavel Stehule wrote:
> Hello
>
> I can't to create module on pgfoundry. It is probably access denied
> problem. Can somebody help me with this?
>
> [pa...@nemesis pstcoll]$ cvs -d
> :ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pstcoll
> no-vendor initial-releas
On 1/25/10 9:45 AM, Selena Deckelmann wrote:
> Hi!
>
> I poked around a little at pg_standby because of some 'cp: file does
> not exist' errors that were cropping up as pg_standby searched around
> for .history files.
>
> I added a stat that still outputs debugging information but now we
> don't
Robert Haas writes:
> I don't think we can change this because "ALTER COLUMN SET STATISTICS"
> is not new in 8.5. We added (and then removed) "ALTER COLUMN SET
> STATISTICS DISTINCT", but that's not the same thing.
> What we COULD do is add a column option called statistics_target and
> then mak
Greg Stark writes:
> Given this thread on pgsql-general I wonder if we should have
> something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
> client socket is still open.
... and do what? If so, why?
regards, tom lane
--
Sent via pgsql-hackers mailing list (
"Kevin Grittner" writes:
> Tom Lane wrote:
>> It might be better to try a test case with lighter-weight objects,
>> say 5 million simple functions.
> Said dump ran in about 45 minutes with no obvious stalls or
> problems. The 2.2 GB database dumped to a 1.1 GB text file, which
> was a little
On Mon, Jan 25, 2010 at 1:05 PM, Baron Schwartz wrote:
> Hi Robert,
>
> On Mon, Jan 25, 2010 at 11:41 AM, Robert Haas wrote:
>> Maybe instead of (or in addition to) providing MySQL-specific help, we
>> should find a way to emphasize the "\d" and "\d table" commands,
>
> Right, it's like "cd" and
On Sun, Jan 24, 2010 at 07:25:24PM +0100, Boszormenyi Zoltan wrote:
> The problem that popped up first was that adjust_informix()
> didn't properly deal with structs, remember? I tried some
Yes, that's what made me wondering.
> i.e. IIRC in some cases adjust_informix() was bypassed
> and the stru
Tom Lane wrote:
> It might be better to try a test case with lighter-weight objects,
> say 5 million simple functions.
Said dump ran in about 45 minutes with no obvious stalls or
problems. The 2.2 GB database dumped to a 1.1 GB text file, which
was a little bit of a surprise.
-Kevin
--
S
Hi Robert,
On Mon, Jan 25, 2010 at 11:41 AM, Robert Haas wrote:
> Maybe instead of (or in addition to) providing MySQL-specific help, we
> should find a way to emphasize the "\d" and "\d table" commands,
Right, it's like "cd" and "ls" at the shell prompt. It's like walking
into a dark room and
Hi!
I poked around a little at pg_standby because of some 'cp: file does
not exist' errors that were cropping up as pg_standby searched around
for .history files.
I added a stat that still outputs debugging information but now we
don't get cp failures, and then added a 'progress' mode. It was a b
Greg Smith wrote:
> Kevin Grittner wrote:
>> Other posts have suggested that "review fests" might be helpful
>> in this period. Again, it sounds to me, from other posts on this
>> thread, as though the primary risk is that people working on the
>> release could see something they couldn't resist
Ross J. Reedstrom wrote:
> On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
> <..>
> > without having to add a switch to their command lines. It's not going
> > to have anything to say to experienced psql users anyway so it would
> > probably not bug anyone enough to turn it of
Ross J. Reedstrom wrote:
So a quick mapping of most-needed commands, and a pointer to the docs for the
full
ramifications and subtle differences seems to fit the existing
documentation module.
And that's been done at least twice already:
http://blog.endpoint.com/2009/12/mysql-and-postgres-
Kevin Grittner wrote:
Other posts have suggested that "review fests" might be helpful in
this period. Again, it sounds to me, from other posts on this
thread, as though the primary risk is that people working on the
release could see something they couldn't resist getting drawn into
-- taking th
On Mon, Jan 25, 2010 at 10:49:55AM -0600, Ross J. Reedstrom wrote:
> On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
> <..>
> > without having to add a switch to their command lines. It's not going
> > to have anything to say to experienced psql users anyway so it would
> > pr
Tom Lane wrote:
> It might be better to try a test case with lighter-weight objects,
> say 5 million simple functions.
A dump of that quickly settled into running a series of these:
SELECT proretset, prosrc, probin,
pg_catalog.pg_get_function_arguments(oid) AS funcargs,
pg_catalog.pg_get_fun
On Mon, Jan 25, 2010 at 06:06:53PM +0200, Alastair Bell Turner wrote:
<..>
> without having to add a switch to their command lines. It's not going
> to have anything to say to experienced psql users anyway so it would
> probably not bug anyone enough to turn it off.
I would so use this feature goi
On Mon, Jan 25, 2010 at 11:14 AM, Andrew Dunstan wrote:
> Alastair "Bell" Turner wrote:
>>
>> If this option is designed to help people's transition - basically to
>> get to them before they've got to most of the manual - having to turn
>> it on will be pointless. It needs to be active by default.
Folks,
When sending a patch, please frame and describe it with a simple
declarative sentence, or at most a short paragraph. If English is not
your preferred language, I can edit what you send. In extreme cases,
I can get it translated.
For examples of this kind of clear message, please refer to
On Mon, Jan 25, 2010 at 6:14 PM, Andrew Dunstan wrote:
>
> My problem with this whole idea is that it seems to be very MySQL-specific.
> Why aren't we providing help for users migrating from Oracle, Sybase,
> Informix, Ingres, DB2, SQLServer and Firebird, to name but a few? And if we
> turn all th
Alastair "Bell" Turner wrote:
If this option is designed to help people's transition - basically to
get to them before they've got to most of the manual - having to turn
it on will be pointless. It needs to be active by default.
My problem with this whole idea is that it seems to be very
M
* Alastair Bell Turner [100125 11:07]:
> If this option is designed to help people's transition - basically to
> get to them before they've got to most of the manual - having to turn
> it on will be pointless. It needs to be active by default. A way to
> avoid it being a default option in psql may
--On 25. Januar 2010 11:39:21 +0900 KaiGai Kohei
wrote:
(echo "CREATE TABLE t (a int);"
for i in `seq 0 9`; do
echo "CREATE TABLE s$i (b int) INHERITS(t);"
for j in `seq 0 9`; do
echo "CREATE TABLE v$i$j (c int) INHERITS(s$i);"
for k in `seq 0 9`; do
Tim Bunce wrote:
FYI I've an updated patch ready but I'll wait till the commitfest has
got 'closer' as there's a fair chance a further update will be needed
anyway to make a patch that applies cleanly.
I want to deal with this today or tomorrow, so don't sit on it, please.
cheers
andr
If this option is designed to help people's transition - basically to
get to them before they've got to most of the manual - having to turn
it on will be pointless. It needs to be active by default. A way to
avoid it being a default option in psql may be setting an alias as
part of package installa
On Sat, Jan 23, 2010 at 06:40:03PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 23, 2010 at 16:16, Tim Bunce wrote:
> > On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> >> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> >> I'd vote for use warnings; as well.
> >
> > I would to, but
2010/1/25 KaiGai Kohei :
> Or, are you saying to test diamond-inheritance cases?
Please go back and read the test case that I already proposed.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On Sun, Jan 24, 2010 at 9:16 PM, Takahiro Itagaki
wrote:
> I found a couple of incomplete syntax when I was adjusting psql
> automatic tab completion for HEAD.
So, I'm slightly confused about whether you want to fix tab completion
or behavior, but...
> 1. We cannot specify tablespace options on
Hello
I can't to create module on pgfoundry. It is probably access denied
problem. Can somebody help me with this?
[pa...@nemesis pstcoll]$ cvs -d
:ext:ok...@cvs.pgfoundry.org:/cvsroot/pstcollection import pstcoll
no-vendor initial-release
Password:
Cannot access /cvsroot/pstcollection/CVSROOT
2010/1/25 Baron Schwartz :
> Hi Cédric,
>
> On Sun, Jan 24, 2010 at 5:11 PM, Cédric Villemain
> wrote:
>> 'psql --help mysql' (or 'psql --tips mysql' ) might be good to call a
>> special helper : I don't see the point to introduce that kind of
>> things when it is useless for most of our users.
>
2010/1/24 Tom Lane :
> Simon Riggs writes:
>> On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
>>> No performance issues
>
>> ISTM that this class of function is inherently dangerous performance
>> wise.
>
>> * It looks incredibly easy to construct enormous lists. We should test
>> the ex
2010/1/25 Tom Lane :
> Pavel Stehule writes:
>> 2010/1/25 Peter Eisentraut :
>>> xmlagg -> concatenates values to form xml datum
>>> array_agg -> concatenates values to form array datum
>>> ??? -> concatenates values to form string datum
>>>
>>> So it's pretty clear that listagg does not fit into
On Monday, January 25, 2010, Stefan Kaltenbrunner
wrote:
> Craig Ringer wrote:
>
> On 23/01/2010 5:30 AM, Radu Ilie wrote:
>
> 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.
>
>
> This has been re
--On 25. Januar 2010 09:30:56 -0500 Robert Haas
wrote:
This will turn into
another setting like search_path and standard_conforming_strings that
can break working code if the actual value doesn't match the
anticipated value. I can't figure out why someone would want to use
this even if we
On Mon, 2010-01-25 at 09:30 -0500, Robert Haas wrote:
> +1 for removing default_do_language, too.
+1 for removing default_do_language OR adding default_language.
I prefer a hard-wired default of PLpgSQL, so a missing language
statement on a DO block is always interpreted the same.
--
Simon Ri
On Mon, Jan 25, 2010 at 3:55 AM, Simon Riggs wrote:
> On Mon, 2010-01-25 at 09:08 +0200, Peter Eisentraut wrote:
>> On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote:
>> > Why do we have a parameter called "default_do_language" when we don't
>> > have a parameter called "default_language"?
>>
>
On Mon, 2010-01-25 at 16:22 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It's clearly a
> > lower priority than other code based upon feedback from the Hot Standby
> > user group.
>
> What's the "the Hot Standby user group"?
A group of people who have an interest in using Hot Stand
Simon Riggs wrote:
> It's clearly a
> lower priority than other code based upon feedback from the Hot Standby
> user group.
What's the "the Hot Standby user group"?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
2010/1/25 Tom Lane :
> Pavel Stehule writes:
>> 2010/1/25 Peter Eisentraut :
>>> xmlagg -> concatenates values to form xml datum
>>> array_agg -> concatenates values to form array datum
>>> ??? -> concatenates values to form string datum
>>>
>>> So it's pretty clear that listagg does not fit into
Given this thread on pgsql-general I wonder if we should have
something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
client socket is still open.
This has come up in the past and the concern was that syscalls would
be way too slow to put in critical loops but perhaps if it's only done
o
Pavel Stehule writes:
> 2010/1/25 Peter Eisentraut :
>> xmlagg -> concatenates values to form xml datum
>> array_agg -> concatenates values to form array datum
>> ??? -> concatenates values to form string datum
>>
>> So it's pretty clear that listagg does not fit into this scheme.
> when you def
Craig Ringer wrote:
On 23/01/2010 5:30 AM, Radu Ilie wrote:
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.
This has been reported on -general, then -bugs, now -hackers, and seems
to just get igno
1 - 100 of 111 matches
Mail list logo
