Bruce Momjian <[EMAIL PROTECTED]> writes:
> If you think it would be easy to get patch submitters to categorize,
> realize we have some very skilled people who don't even send email
> reports of bugs, they just report them on IRC and can't be bothered with
> email. If email is a burden for them, i
Alvaro Herrera wrote:
> Gregory Stark wrote:
>
> > so I went to look for the held patches queue to start reviewing patches.
> > There are over 2000 messages in the queue in 300 separate threads. At that
> > rate it would probably be just as easy to scan the patches and hackers
> > mailing
> >
Hi Andrew-san.
- Original Message -
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
How the heck are we going to document this reasonably? It strikes me as
horribly complicated and puzzling for users. The current rule might be
an annoyance in porting applications, but it has the advantage
Hiroshi Saito wrote:
> Sorry, I'm sleeping.
> Thanks Gregory-san. and, Tom-san.
>
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> But yeah, c_expr isn't enough. We really need {a,b}_expr sans postfix
>>> expressions.
>>
>> How's that going to help? As long as postfix operators exist at all,
>>
>
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
Oops, and,
so we really need to support at least ColId as the allowed set of
column alias names. (I tried changing the patch to do that, but
got a lot of shift/reduce conflicts, som
Sorry, I'm sleeping.
Thanks Gregory-san. and, Tom-san.
Gregory Stark <[EMAIL PROTECTED]> writes:
But yeah, c_expr isn't enough. We really need {a,b}_expr sans postfix
expressions.
How's that going to help? As long as postfix operators exist at all,
SELECT a + b, ...
is going to be ambigu
Gregory Stark <[EMAIL PROTECTED]> writes:
> But yeah, c_expr isn't enough. We really need {a,b}_expr sans postfix
> expressions.
How's that going to help? As long as postfix operators exist at all,
SELECT a + b, ...
is going to be ambiguous, and no amount of grammar magic changes that.
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> Oops, and,
>>> so we really need to support at least ColId as the allowed set of
>>> column alias names. (I tried changing the patch to do that, but
>>> got a lot of shift/reduce conflicts, some of which are maybe fixable
>>> but some seem hard to fix
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> Oops, and,
>>> so we really need to support at least ColId as the allowed set of
>>> column alias names. (I tried changing the patch to do that, but
>>> got a lot of shift/reduce conflicts, some of which are maybe fixable
>>> but some seem hard to fix.
Decibel! wrote:
> For that matter, it'd be better if you could just get all 3 files (pre,
> data, post) in one shot with one transaction; that would guarantee you a
> clean dump.
+1.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consultin
Simon Riggs escribió:
> On Fri, 2008-02-08 at 08:45 +0600, Markus Bertheau wrote:
>
> > What about allowing shared_buffers to be only greater than it was at
> > server start and allocating the extra shared_buffers in one or more
> > additional shm segments?
>
> Sounds possible.
Hmm, but then you
Oops, and,
so we really need to support at least ColId as the allowed set of
column alias names. (I tried changing the patch to do that, but
got a lot of shift/reduce conflicts, some of which are maybe fixable
but some seem hard to fix.)
Since capability was insufficient, I spent several times
Hi.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
Hmm, since c_expr is so restrictive, is that really going to satisfy
anybody who expects to be able to omit AS? With the number of
unreserved keywords we have, the restriction to IDENT for the label
seems like it's going
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> *** src/backend/parser/gram.y 4 Feb 2008 06:35:46 - 1.1
> --- src/backend/parser/gram.y 4 Feb 2008 17:24:19 - 1.2
> ***
> *** 8320,8325
> --- 8320,8333
> $$->val = (Node *)
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Thu, Feb 07, 2008 at 06:58:25PM -0500, Tom Lane wrote:
>> This problem applies to SSPI too, correct?
> Yeah, they work the same way.
OK, I've fixed the server side to complain before any unparsable data
is sent or received. But this happens after
On Fri, Feb 08, 2008 at 06:42:07AM +, Simon Riggs wrote:
> On Fri, 2008-02-08 at 08:45 +0600, Markus Bertheau wrote:
>
> > What about allowing shared_buffers to be only greater than it was at
> > server start and allocating the extra shared_buffers in one or more
> > additional shm segments?
>
Hi.
I apologizes for impoliteness. sorry.
I cause misapprehension since telling well is difficult for me.
From: "Tom Lane" <[EMAIL PROTECTED]>
It's certainly possible that some of the buildfarm machines use locales
that haven't been covered --- or at least weren't covered when you
starte
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is quite untrue; we have variant regression files that exist
>> specifically to support running the tests under various popular locales.
> I know I had enough trouble even before we started doing Windows builds
> that we had to
Hi all.
I thinks to the option of "AS" by the syntax of table reference.
The problem on structure had restricted it until now. Then,
conversion was required of this by the degree of migration from
other DBMS's. It was irritated a little.
I understood that it was an option in SQL2003 and SQL99.
Hi.
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
I stand corrected.
I know I had enough trouble even before we started doing Windows builds
that we had to use --no-locale in the buildfarm (or at least that was
the solution I adopted).
For example, I know of cases where FBSD and Linux don't
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Since we rely on the OS to supply locale settings, getting a reliable
set of regression tests that depended on the locale would be close to
impossible. We really have to run the regression tests under --no-locale.
This is qu
On Wed, Feb 06, 2008 at 05:10:00PM +0100, Zeugswetter Andreas ADI SD wrote:
> Simon wrote:
> > My proposal is to provide two additional modes:
> > --schema-pre-load corresponding to (1) above
> > --schema-post-load corresponding to (3) above
>
> Sounds nice.
> For a large schema we might rather w
Um, I was flipped off by you
You shouldn't go around flipping people off: it's rude :)
http://www.merriam-webster.com/dictionary/flip%20off
Ah sorry, I was the reason referred to as being an aphasic.
It was not meant expression. :-(
However, I think then that I was not fair.
--
On Sat, 9 Feb 2008, Hiroshi Saito wrote:
> Um, I was flipped off by you
You shouldn't go around flipping people off: it's rude :)
http://www.merriam-webster.com/dictionary/flip%20off
---(end of broadcast)---
TIP 4: Have you searched our list archiv
Hi Tom-san.
From: "Tom Lane" <[EMAIL PROTECTED]>
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Since we rely on the OS to supply locale settings, getting a reliable
set of regression tests that depended on the locale would be close to
impossible. We really have to run the regression tests under
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Since we rely on the OS to supply locale settings, getting a reliable
> set of regression tests that depended on the locale would be close to
> impossible. We really have to run the regression tests under --no-locale.
This is quite untrue; we have var
Gevik Babakhani wrote:
> >
> > Surely it should be the inverse of the solution for output,
> > eg TMMon selects localized input.
> >
>
> After some investigation in how gettext works, I would like to have your
> opinion about how to
> implement this TODO item.
>
> Starting with TO_CHAR:
>
>
On Fri, Feb 08, 2008 at 12:22:08PM -0300, Alvaro Herrera wrote:
> Gregory Stark wrote:
> > Is someone working on dumping the list into a table on the wiki? I could
> > download the mbox files from the web site and filter them into a table.
> >
> > Some part of me thinks this data should be in a po
Andrew Dunstan escribió:
> Alvaro Herrera wrote:
>> Florian Pflug escribió:
>> Yeah, the SVN mirror in commandprompt.com is recreated from scratch
>> every time. This sucks, we know -- I think it's on Joshua's list to
>> change it to update incrementally.
>
> Can you document what you actually
On Fri, 08 Feb 2008 10:25:33 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > Yeah, the SVN mirror in commandprompt.com is recreated from scratch
> > every time. This sucks, we know -- I think it's on Joshua's list to
> > change it to update incrementally.
> >
> >
>
> Can you document wha
Alvaro Herrera wrote:
Florian Pflug escribió:
I've tried with both the SVN and the GIT mirror. Things worked well
initialled, but in *both* cases pulling changes from the mirror stopped
working after a few weeks or so. It seems that both of these mirrors
create the SVN/GIT repo from s
Gregory Stark wrote:
> so I went to look for the held patches queue to start reviewing patches.
> There are over 2000 messages in the queue in 300 separate threads. At that
> rate it would probably be just as easy to scan the patches and hackers mailing
> list.
Pretty unwieldy, yes. I'm not
Tom Lane wrote:
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
Le Wednesday 06 February 2008 21:35:54 Peter Eisentraut, vous avez écrit :
Yes, I feel we could use a group writeable patch queue of some sort.
Perhaps an IMAP server setup could do the job.
I've read some developers appreciating t
* Florian Pflug <[EMAIL PROTECTED]> [080208 09:25]:
> Aidan Van Dyk wrote:
> >The Git repo certainly is an "incremental" update.
> >
> >If you ever see a "rewind" (non-fastforward) of the the repo.or.cz
> >PostgreSQL repo, please let me know...
>
> Hm... interesting...
>
> I'm pretty sure that th
so I went to look for the held patches queue to start reviewing patches.
There are over 2000 messages in the queue in 300 separate threads. At that
rate it would probably be just as easy to scan the patches and hackers mailing
list.
Is someone working on dumping the list into a table on the w
Aidan Van Dyk wrote:
The Git repo certainly is an "incremental" update.
If you ever see a "rewind" (non-fastforward) of the the repo.or.cz
PostgreSQL repo, please let me know...
Hm... interesting...
I'm pretty sure that the "past" changed at least once - at least I once
got loud complaints f
Florian Pflug escribió:
> I've tried with both the SVN and the GIT mirror. Things worked well
> initialled, but in *both* cases pulling changes from the mirror stopped
> working after a few weeks or so. It seems that both of these mirrors
> create the SVN/GIT repo from scratch every time the
Hi Andrew-san.
Thanks!
- Original Message -
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
Hiroshi Saito wrote:
Hi Tom-san.
I look at that all regression tests pass by tools/msvc. It is very
comfortable.!
Then, the reason, it is because no-locale is an default value.
Since we r
Hiroshi Saito wrote:
Hi Tom-san.
I look at that all regression tests pass by tools/msvc. It is very
comfortable.!
Then, the reason, it is because no-locale is an default value.
Since we rely on the OS to supply locale settings, getting a reliable
set of regression tests that depended on
Hi Tom-san.
I look at that all regression tests pass by tools/msvc. It is very comfortable.!
Then, the reason, it is because no-locale is an default value.
--
my @args = (
"../../../$Config/pg_regress/pg_regress",
"--psqldir=../../../$Config/psql",
"--schedule=${schedule}_
The Git repo certainly is an "incremental" update.
If you ever see a "rewind" (non-fastforward) of the the repo.or.cz
PostgreSQL repo, please let me know...
a.
* Florian Pflug <[EMAIL PROTECTED]> [080208 07:50]:
> I've tried with both the SVN and the GIT mirror. Things worked well
> initiall
Peter Eisentraut wrote:
Am Freitag, 8. Februar 2008 schrieb Brendan Jurd:
In particular, if the git repos were officially supported, and best
practises for use with Postgres documented, I think a lot more hackers
would be comfortable using git to do their work, which is good for
collaboration (a
Am Freitag, 8. Februar 2008 schrieb Brendan Jurd:
> In particular, if the git repos were officially supported, and best
> practises for use with Postgres documented, I think a lot more hackers
> would be comfortable using git to do their work, which is good for
> collaboration (as mentioned by Greg
On Feb 8, 2008 10:29 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Am Freitag, 8. Februar 2008 schrieb Markus Bertheau:
> > Maybe the existing SVN, git and other mirrors could just become more
> > official and supported in the sense that users can rely on them to be
> > updated often enough?
>
Am Freitag, 8. Februar 2008 schrieb Markus Bertheau:
> Maybe the existing SVN, git and other mirrors could just become more
> official and supported in the sense that users can rely on them to be
> updated often enough?
I think you are right. Some of that is already being worked on. It certainly
2008/2/8, Heikki Linnakangas <[EMAIL PROTECTED]>:
> Gregory Stark wrote:
> > git or its ilk would impact the lives of submitters and reviewers most.
> > Basically it would allow two non-committers to collaborate, something
which we
> > can't really do effectively now.
>
> Two git-using non-committe
On Fri, Feb 08, 2008 at 09:59:37AM +0100, Dawid Kuroczko wrote:
> That is true. However it is possible to allocate more than one shared memory
> segment. At simplest I would assume that DBA should specify minimum
> shared memory size (say, 1GB) and expected maximum (2GB). And that
> between mini
On Friday 08 February 2008 00:52:04 Gregory Stark wrote:
> Well not really. Our current model is that only stuff that's ready for
> widespread use goes into CVS. That means "everything" isn't open and shared
> at all. "everything" is mostly sitting on people's local hard drives where
> you can't u
On Feb 7, 2008 11:59 PM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 07, 2008 at 08:22:42PM +0100, Dawid Kuroczko wrote:
> > Nw, I know work_mem is not "total per process limit", but
> > rather per sort/hash/etc operation. I know the scheme is a bit
> > sketchy, but I think
> > while we are at it -- one feature would be great for 8.4, an
> > ability to shange shared buffers size "on the fly". I expect
> > it is not trivial, but would help fine-tuning running database.
> > I think DBA would need to set maximum shared buffers size
> > along the normal setting.
>
On Thu, Feb 07, 2008 at 06:58:25PM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I vote we just decide that GSS isn't going to be supported on protocol
> >> V2, and put a suitable error message into the server for that. It
> >> doesn't seem to me tha
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Therefore, we can provide mirrors of the CVS repository in multiple formats.
And those mirrors exist already, I remember a GIT and a Subversion mirror off
the top of my head, and I bet there's others. After we have that, the
52 matches
Mail list logo