Robert Haas wrote:
On Wed, Apr 1, 2009 at 3:49 PM, Sam Mason s...@samason.me.uk wrote:
On Wed, Apr 01, 2009 at 03:19:23PM -0400, Robert Haas wrote:
On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler da...@kineticode.com wrote:
Well, I'd just point out that the return value of string_to_array()
Robert Haas wrote:
On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Both of those things are related to 8.4 feature changes, so we should
either do them now or
Considering the following sequence:
create table t(a int primary key);
alter table t drop constraint t_pkey;
insert into t values(null);
ERROR: null value in column a violates not-null constraint
My question is, why null is not allowed to be inserted after primary key
constraint
On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
As Dave Page pointed
out, other people have already started designing tools based on CVS
HEAD.
Now is the time to decide, before the PostgreSQL beta is out. I understand
the pain inflicted on
Tom Lane wrote:
A problem with such caching is that it'd fail to respond to changes in
the content of pg_conversion. Now the code is already pretty
insensitive in that respect, because if you're not doing any fresh SET
client_encoding commands it won't ever notice changes in that catalog
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
I've seen a couple of reports that the new SSL error messages on windows
look strange with paths the wrong way. For example:
root certificate file C:\Documents and Settings\SNIP\Application
Data/postgresql/root.crt does not exist.
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
What makes more sense to me is to add a table to encnames.c that
provides the gettext name of every encoding that we support.
Do you mean a separate table there, or should we add a new column to one
of the existing
I'm speaking primarily of functions as first-class objects, though
closures would be nice too. But consider an operation like
UPDATE rel SET col1 = MAP ( f OVER col2 )
We need to be able to determine whether this is well-typed, just as we
do now for any other SQL query. Specifically, we
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Maybe use a special string Translate Me First that
doesn't actually need to be end-user-visible, just so no one sweats
over
getting it right in context.
Yep, something
On Thu, Apr 2, 2009 at 3:25 AM, Jacky Leng lengjianq...@163.com wrote:
Considering the following sequence:
create table t(a int primary key);
alter table t drop constraint t_pkey;
insert into t values(null);
ERROR: null value in column a violates not-null constraint
My question
Hi,
Considering the following sequence:
create table t(a int primary key);
alter table t drop constraint t_pkey;
insert into t values(null);
ERROR: null value in column a violates not-null constraint
My question is, why null is not allowed to be inserted after primary
On Thu, Apr 2, 2009 at 8:24 AM, Nikhil Sontakke
nikhil.sonta...@enterprisedb.com wrote:
Hi,
Considering the following sequence:
create table t(a int primary key);
alter table t drop constraint t_pkey;
insert into t values(null);
ERROR: null value in column a violates
Bug #4694
(http://archives.postgresql.org/message-id/200903050848.n258mvgm046...@wwwmaster.postgresql.org)
shows a very strange behaviour on windows when you use a different case PATH
From what I can tell, this is because dir_strcmp() is case sensitive,
but paths on windows are really
Hi,
Making a column into the primary key forces the column to NOT NULL.
You'll need to DROP NOT NULL separately.
It's probably possible to beat on the code hard enough to fix this,
Yeah it will be a matter of finding the affected column entries and
invoking
the removal of the not
Robert Haas robertmh...@gmail.com writes:
Actually it's more complicated than that. You'd need to remember
whether or not the NOT NULL was added when the primary key was added,
or whether it was there before, and only drop it if it wasn't there
before.
We've discussed before the idea that
The sgml doc mentions about HeapTupleSatisfiesNow() but currently we
have HeapTupleSatisfiesVisibility() instead.
Regards,
diff --git a/doc/src/sgml/pgstattuple.sgml b/doc/src/sgml/pgstattuple.sgml
index 821f631..0bba5fe 100644
--- a/doc/src/sgml/pgstattuple.sgml
+++
Magnus Hagander mag...@hagander.net writes:
Attached patch fixes this in my testcase. Can anybody spot something
wrong with it?
It depends on tolower(), which is going to have LC_CTYPE-dependent
behavior, which is surely wrong?
regards, tom lane
--
Sent via
Dave Page wrote:
On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
As Dave Page pointed
out, other people have already started designing tools based on CVS
HEAD.
Now is the time to decide, before the PostgreSQL beta is out. I understand
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Attached patch fixes this in my testcase. Can anybody spot something
wrong with it?
It depends on tolower(), which is going to have LC_CTYPE-dependent
behavior, which is surely wrong?
Not sure, really :) That's the encoding we'd
Tao Ma feng_e...@163.com writes:
Is it really important to show the
'bpchar' if there is no any explicit casting for the column default value.
Yeah. We cannot say char because per SQL spec, that means char(1),
but there mustn't be a restriction to a single character here.
regression=# select
Dave Page dp...@pgadmin.org writes:
On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Now is the time to decide, before the PostgreSQL beta is out. I understand
the pain inflicted on tools, but I don't think that's a good reason to not
change it.
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
Would introducing a Duration (i.e., time-series
a'la Date, et al)) data type be considered useful?
I'd
Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Now is the time to decide, before the PostgreSQL beta is out. I understand
the pain inflicted on tools, but I don't think that's a good reason to
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
Comments?
Certainly seems like a reasonable compromise. From what I understand,
you'll get this failed to commit... message *if* you have changedf
things in pg_conversion. I think that's acceptable - it's not like
people modify
On Thu, Apr 2, 2009 at 3:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I think the naming decision is close enough to be a coin
toss, and so either choice is fine with me. However, I think it is
Clearly Unacceptable for createdb's switches to be spelled differently
than the underlying
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
It depends on tolower(), which is going to have LC_CTYPE-dependent
behavior, which is surely wrong?
Or are you just saying we should be using pg_tolower()? (which I forgot
about yet again)
Well, I'd be happier with pg_tolower,
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
Personally I think the naming decision is close enough to be a coin
toss, and so either choice is fine with me. However, I think it is
Clearly Unacceptable for createdb's switches to be spelled differently
than the underlying SQL
Dave Page dp...@pgadmin.org writes:
In this case, createdb - however, this particular case is of very
minor impact to us. My gripe is more on the general issue of being
potentially forced to add support for a new version and beta test
tools in the same timeframe that PostgreSQL has for beta.
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
Personally I think the naming decision is close enough to be a coin
toss, and so either choice is fine with me. However, I think it is
Clearly Unacceptable for createdb's switches to be spelled differently
than
Tom Lane t...@sss.pgh.pa.us wrote:
Tao Ma feng_e...@163.com writes:
Is it really important to show the 'bpchar' if there is no any
explicit casting for the column default value.
Yeah. We cannot say char because per SQL spec, that means
char(1), but there mustn't be a restriction to a
Hello,
I am learning how to hack PostgreSQL, but it is still so difficult in fact, I
am a novice!
I am trying to change syntax of postgresql (for my project). I access to
gram.y, I add the changes but I still receive message error (syntax error at
near …).
Is that only change to do
Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
In this case, createdb - however, this particular case is of very
minor impact to us. My gripe is more on the general issue of being
potentially forced to add support for a new version and beta test
tools in the same timeframe that
On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
In this case, createdb - however, this particular case is of very
minor impact to us. My gripe is more on the general issue of being
potentially forced to add support for a new version and
Dave Page wrote:
On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
In this case, createdb - however, this particular case is of very
minor impact to us. My gripe is more on the general issue of being
potentially forced to add support
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
It depends on tolower(), which is going to have LC_CTYPE-dependent
behavior, which is surely wrong?
Or are you just saying we should be using pg_tolower()? (which I forgot
about yet again)
Well, I'd be happier
Attached patch applied, including documentation updates; I think this
is the best we are going to do to balance usability and consistency. I
have removed this as an open 8.4 item.
With this change \dfS and \df * do the same thing; I assume we don't
want to remove the 'S' modifier and tell
Magnus Hagander mag...@hagander.net writes:
And this only shows up when the binary is found in the PATH and not
through a fully specified directory. This is, AFAICT, the only case
where they can differ. This is the reason why we haven't had any reports
of this before - nobody using the
Hitoshi Harada umi.tan...@gmail.com writes:
The sgml doc mentions about HeapTupleSatisfiesNow() but currently we
have HeapTupleSatisfiesVisibility() instead.
I think the wording is fine (and more useful) as-is. Remember
HeapTupleSatisfiesVisibility is just a macro, and since we are calling
it
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
Would introducing a Duration (i.e., time-series
a'la
Consider two tables foo(x int not null) and bar (x int).
I fire the sql
SQL1: alter table bar inherit foo;
Above sql causes ERROR: column x in child table must be marked NOT NULL.
This looks logically fine to me.
So, I fire the sql
SQL2: alter table bar alter column x set not null;
Then I
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example
of something like '1,2,,4'.
I can't see that there's any way to do this in SQL regardless of how
we define this operation.
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work for empty strings (except most of the
time, it does). The former is sounding
Hi, the problem goes on. I think the problem is in the planner.c on
grouping_planner function, because when I do a regular sort it gets to it:
/*
* If we were not able to make the plan come out in the right order, add
* an explicit sort step.
*/
if (parse-sortClause)
{
K. Srinath k.srin...@gmail.com writes:
Why is this so?
Because we don't track inheritance state for attnotnull. There is no
way you can make it work right with marginal hacking on the ATExec
code, because there just isn't enough state.
The correct fix is probably the one alluded to in another
Martin Pihlak wrote:
Attached is a patch that modifies psql \dX commands to treat objects
in information_schema as system objects. This prevents them from
showing up in \dX *.* and polluting the user objects list. This is
especially annoying if user objects are in multiple schemas, and
one
On Thu, Apr 2, 2009 at 12:17 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work
K. Srinath k.srin...@gmail.com writes:
I'm implementing global index - an index that indexes all tables in
an inheritance hierarchy.
This is probably not a good project to tackle as your first Postgres
patch.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Thu, Apr 2, 2009 at 12:10 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example of
something like '1,2,,4'.
I can't see that
On Thu, Apr 2, 2009 at 10:59 AM, K. Srinath k.srin...@gmail.com wrote:
5. gbl_indx_wip1: patch file w.r.t. anoncvs checkout dated 1 Dec 08.
please, update your patch to current HEAD... and add it to
http://wiki.postgresql.org/wiki/CommitFestInProgress
--
Atentamente,
Jaime Casanova
Soporte y
On Thu, Apr 2, 2009 at 10:44 AM, abdelhak benmohamed
abdelhak.benmoha...@yahoo.fr wrote:
I am trying to change syntax of postgresql (for my project). I access to
gram.y, I add the changes but I still receive message error (syntax error at
near …).
Is that only change to do or are their other
On 4/2/09 8:48 AM, David E. Wheeler wrote:
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
Would
David E. Wheeler da...@kineticode.com writes:
Or we could stick to the current behavior and say use COALESCE() to
resolve the ambiguity, if you need to.
Steve has a point that leaving it as-is leaves it as impossible to
tell the difference between string_to_array(NULL, ',') and
Thank you, fixed
I’ve found a bug about hstore, example below:
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out their choice of
the above. Seems like this is the worst of all possible worlds.
We should probably pick one or the
The nature of the problem is this: if gist_box_picksplit doesn't find
a good disposition on the first try, then it tries to split the data
again based on the positions of the box centers. But there's a problem
here with floating-point rounding; it's possible for the average of N
Look at the
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out their choice of
the above. Seems like this is the worst of all possible
Josh Berkus wrote:
On 4/2/09 8:48 AM, David E. Wheeler wrote:
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some
On Thu, Apr 02, 2009 at 02:04:41PM -0400, Tom Lane wrote:
A correct fix
outside-the-function would look more like
case when str = '' then '{}'::text[] else string_to_array(str, ',') end
which should correctly yield NULL for NULL input and an empty array
for empty input. Similarly, if
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
Personally I think the naming decision is close enough to be a coin
toss, and so either choice is fine with me. However, I think it is
Clearly Unacceptable for createdb's switches to be spelled
Teodor Sigaev teo...@sigaev.ru writes:
Look at the patch, it fixes the problem by comparing for equality by FPeq()
macros which is used everywhere in geometry calculation.
Ick. FPeq() is a crock; I'd like to see us get rid of it, not spread it
even further. And what confidence do you have
Hi,
I don't know exactly what you want to do but you can begin by looking
here http://neilconway.org/talks/hacking/ (in particular Handout with
excerpts from patch).
can you tell us more ?
Amine
abdelhak benmohamed a écrit :
Hello,
I am learning how to hack PostgreSQL, but it is
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out their
On Thu, 2009-04-02 at 21:19 +0300, Heikki Linnakangas wrote:
The data type itself is quite trivial. It's all the operators that are
more difficult to implement, and also immensely useful. That part is
still incomplete.
Can you please let me know what you find lacking (note: the SVN repo is
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Now, what about the idea of providing a shorthand LOCALE='foo',
mirroring --locale=foo initdb option? It seems like a good idea, because
you almost never want to set LC_COLLATE and LC_CTYPE differently. If we
do that, should
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If there's a camp that actually *wants* a NULL result for this case,
I missed the reasoning.
So that we don't break existing apps because of an issue that is
trivial to work around.
even further. And what confidence do you have that this change
eliminates all forms of the problem, anyway?
Yes, I think. Because that part of code ( if (IS_BADRATIO) {...} ) is a corner
case itself. In example from Andrew, all boxes are placed to one page because of
floating-point rounding.
Jeff Davis wrote:
On Thu, 2009-04-02 at 21:19 +0300, Heikki Linnakangas wrote:
The data type itself is quite trivial. It's all the operators that are
more difficult to implement, and also immensely useful. That part is
still incomplete.
Can you please let me know what you find lacking (note:
Pavel Stehule pavel.steh...@gmail.com writes:
Our implementation of variadic parameters are not complete. The
support of any type is incomplete. Modificator VARIADIC for funccall
parameters needs transformation from ArrayExpr to standard parameters
list.
I don't think I agree with this
OK, updated patch attached and applied; thanks.
---
Zdenek Kotala wrote:
It looks OK now.
Zdenek
Dne 8.03.09 21:58, Robert Lor napsal(a):
2) Maybe
TRACE_POSTGRESQL_SLRU_READPAGE_PHYSICAL_DONE(true,
On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:
Yes, I'd be tempted to pick one and go with it. It's seems a
completely
arbitrary choice one way or the other but the current behaviour is
certainly wrong.
I'd go with returning a zero element array because it would do
the right thing more often
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Teodor Sigaev teo...@sigaev.ru writes:
Look at the patch, it fixes the problem by comparing for equality
by FPeq() macros which is used everywhere in geometry calculation.
Tom Ick. FPeq() is a crock; I'd like to see us get rid of it, not
Tom
Thanks, patch applied.
---
Andrew Gierth wrote:
Bruce == Bruce Momjian br...@momjian.us writes:
hi all,
I read the code that it seems easy for the cursor in plpgsql to
return ROW_COUNT after MOVE LAST etc.
On Thursday 02 April 2009 18:29:45 Tom Lane wrote:
Hmm. Well, if we use pg_tolower then it will only do the right thing
for ASCII letters, but it seems like non-ASCII in the path leading to
the postgres binaries would be pretty dang unusual.
Well, Windows localizes the directory names like
On Thu, 2009-03-26 at 17:15 +, Tom Lane wrote:
Log Message:
---
If we expect a hash join to be performed in multiple batches, suppress
physical tlist optimization on the outer relation (ie, force a projection
step to occur in its scan). This avoids storing useless column values
On Thu, 2009-04-02 at 21:58 +0300, Heikki Linnakangas wrote:
I have not yet implemented temporal join.
That, and temporal union and difference. You have a union operator, but
that's not enough for a temporal union, as in:
Ok, so you were talking about the relational operators, not interval
On Monday 30 March 2009 15:52:37 Heikki Linnakangas wrote:
What is happening is that gettext() returns the message in the encoding
determined by LC_CTYPE, while we expect it to return it in the database
encoding. Starting with PG 8.3 we enforce that the encoding specified in
LC_CTYPE matches
Simon Riggs si...@2ndquadrant.com writes:
Can we add batches=N to the EXPLAIN output for Hash and/or Hash Join?
Are you talking about expected batches, or actual batches? If the
former, would it be sufficient to distinguish 1 from more than 1?
If so, maybe changing the node title to Batched
Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Joshua D. Drake wrote:
Do we want to give a more informative error message, like not supported
on this platform?
The trick will be to fit this into the GUC framework.
You could do it by enforcing
Teodor == Teodor Sigaev teo...@sigaev.ru writes:
even further. And what confidence do you have that this change
eliminates all forms of the problem, anyway?
Teodor Yes, I think. Because that part of code ( if (IS_BADRATIO)
Teodor {...} ) is a corner case itself. In example from Andrew,
On Thu, Apr 2, 2009 at 2:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If there's a camp that actually *wants* a NULL result for this case,
I missed the reasoning.
So that we don't break
Andrew Gierth and...@tao11.riddles.org.uk writes:
I think that not only does there need to be another IS_BADRATIO check,
but also there needs to be some sort of backstop in gistSplit or
gistUserPicksplit to either recover or (as a last resort) error out
cleanly rather than crash the entire db
On Thu, Apr 2, 2009 at 2:58 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Also, it would be nice to generalize the thing so that it works not only
with intervals of time, but also floats, integers, numerics etc. The concept
of an interval is not really tied to timestamps,
2009/4/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Our implementation of variadic parameters are not complete. The
support of any type is incomplete. Modificator VARIADIC for funccall
parameters needs transformation from ArrayExpr to standard parameters
list.
On Thu, 2009-04-02 at 15:49 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Can we add batches=N to the EXPLAIN output for Hash and/or Hash Join?
Are you talking about expected batches, or actual batches?
Expected batches for EXPLAIN, both for EXPLAIN ANALYZE.
If the
Pavel Stehule pavel.steh...@gmail.com writes:
actually, there isn't any difference between a) and b)
a) select somevariadicwithany(10);
b) select somevariadicwithany(variadic 10);
in this case the keyword VARIADIC is ignored.
Well, in my mind what the VARIADIC keyword does is it prevents
After talking to Tom, I have reverted this patch. It does not contain
documentation, and are not properly placed, and was submitted in
February. I was hoping it would be an easy addition but obviously not
so please resubmit for 8.5. Sorry.
2009/4/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
actually, there isn't any difference between a) and b)
a) select somevariadicwithany(10);
b) select somevariadicwithany(variadic 10);
in this case the keyword VARIADIC is ignored.
Well, in my mind what the
Bruce Momjian br...@momjian.us writes:
After talking to Tom, I have reverted this patch. It does not contain
documentation, and are not properly placed, and was submitted in
February. I was hoping it would be an easy addition but obviously not
so please resubmit for 8.5. Sorry.
Aside from
All,
Please:
A. Stop cc'ing this thread to the WWW list.
B. Please change the topic of this thread to Duration or Time types.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tena Sakai tsa...@gallo.ucsf.edu writes:
I often use a line like:
psql -tf query.sql mydatabase query.out
-t option gets rid of the heading and count
report at the bottom. There is a blank line
at the bottom, however. Is there any way to
have psql not give me that blank line?
Doesn't
Hi Tom,
I am a bit surprised to hear that that '\n'
is there unconditionally. But I am sure
there are more pressing things for you to
work on. It's something I can live with.
Regards,
Tena Sakai
tsa...@gallo.ucsf.edu
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Tom Lane wrote:
Tena Sakai tsa...@gallo.ucsf.edu writes:
I often use a line like:
psql -tf query.sql mydatabase query.out
-t option gets rid of the heading and count
report at the bottom. There is a blank line
at the bottom, however. Is there any way to
have psql not give
While investigating some performance problems recently I've had cause
to think about the way PostgreSQL uses hash joins. So here are a few
thoughts. Some of these have been brought up before.
1. When the hash is not expected to spill to disk, it preserves the
pathkeys of the outer side of the
On Thu, Mar 19, 2009 at 4:04 AM, ITAGAKI Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
Works for me. Especially if you want to think more about ANALYZE before
changing that.
Well, it's something that would be sane to contemplate adding in 8.4.
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Maybe use a special string Translate Me First that
doesn't actually need to be end-user-visible, just so no one sweats
over
getting it right in
Michael Renner wrote:
Hi,
small patch for the documentation describing the current pg_start_backup
checkpoint behavior as per
http://archives.postgresql.org//pgsql-general/2008-09/msg01124.php .
Should we note down a TODO to revisit the current checkpoint handling?
best regards,
Happened to notice this while looking for something else; the \ef
command appears to be missing from \? output. Suggested patch below.
--
Andrew (irc:RhodiumToad)
Index: src/bin/psql/help.c
===
RCS file:
Bruce Momjian br...@momjian.us writes:
+ ereport(NOTICE,
+ (errmsg(performing checkpoint)));
You've *got* to be kidding.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Bruce Momjian wrote:
Michael Renner wrote:
+ processing. Unfortunately it's currently not possible to expedite
+ the checkpointing done by pg_start_backup.
/para
/listitem
listitem
I have combined the above patch with another change that reports a
checkpoint is taking
Robert Haas wrote:
While investigating some performance problems recently I've had cause
to think about the way PostgreSQL uses hash joins. So here are a few
thoughts. Some of these have been brought up before.
1. When the hash is not expected to spill to disk, it preserves the
pathkeys of
1 - 100 of 101 matches
Mail list logo
