Hi,
On 07/15/2010 10:37 PM, Alvaro Herrera wrote:
BTW I think this patch series makes sense, though I haven't looked at it
in detail. I guess it means I'll have to have a look at the IMessages
stuff as well.
Yes, only after adding these patches to the commit fest, I realized that
I'dd have
On 16/07/10 03:26, Boxuan Zhai wrote:
PS: Heikki asked me about what the EXPLAIN MERGE ... command will do.
Well, I have not test it, but it may through an error or just explain the
top plan, since I put the action plans in a new field, which cannot be
recognized by old functions.
I meant what
On Thu, 2010-07-15 at 21:57 -0400, Robert Haas wrote:
Exactly which commands are we going to support? With exactly what
syntax? What information will be returned by each command? In what
format? We have no agreement on any of these points.
The normal process is that we discuss the
On 13/07/10 21:36, Tom Lane wrote:
Dave Pagedp...@pgadmin.org writes:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
On Thu, Jul 15, 2010 at 12:16 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 14, 2010 at 2:50 AM, Fujii Masao masao.fu...@gmail.com wrote:
The patch have no features for performance improvement of synchronous
replication. I admit that currently the performance overhead in the
master
On Jul 15, 2010, at 6:43 PM, Magnus Hagander wrote:
On Thu, Jul 15, 2010 at 18:35, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote:
Is there an actual common use-case for having these commands available
for *non-psql* interfaces?
There
On Mon, May 31, 2010 at 8:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-05-31 at 20:11 +0900, Fujii Masao wrote:
On Thu, May 13, 2010 at 8:39 PM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Ensure that top level aborts call XLogSetAsyncCommit(). Not
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
Thanks for reminding me. I attached the updated patch.
This patch left uncommitted for half a month. No one is interested in
the patch?
The patch adds the document about the relationship between a restartpoint
and
On Tue, Jul 6, 2010 at 9:59 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Truncating seems like an ugly kluge that's not fixing the real problem.
Why are there open descriptors for a dropped relation? They should all
get closed as a consequence
Hi,
For the EXPLAIN MERGE command, I expect it to return a result similar to
that of a SELECT command.
I think the EXPLAIN command is to show how the tables in a query is scaned
and joined. In my design, the merge command will generate a top-level query
(and plan) as the main query. It is in
On 16/07/10 12:26, Boxuan Zhai wrote:
For the EXPLAIN MERGE command, I expect it to return a result similar to
that of a SELECT command.
I think the EXPLAIN command is to show how the tables in a query is scaned
and joined. In my design, the merge command will generate a top-level query
(and
Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
...
We should also check the value not to be something like 0699.
How about checking it with (file_mode ~0666) != 0 ?
...
I want show_log_file_mode to print the setting value in octal format.
It seems like a whole lot of
On 16/07/10 10:40, Fujii Masao wrote:
So we should always prevent the standby from applying any WAL in pg_xlog
unless walreceiver is in progress. That is, if there is no WAL available
in the archive, the standby ignores pg_xlog and starts walreceiver
process to request for WAL streaming.
That
Hi all,
I was reading a post from Sushant Sinha about english parser wich do not
consider dot as a word delimiter. In a following mail it has been proposed
to add a patch.
Is there any news about that ?
I would enjoy this patch, too ;)
Thank's
--
Paul Fariello
Étudiant ingénieur à
Hi
Should we put some externally managed languages , like pl/proxy also in
pgtemplate, so that CREATE LANGUAGE would work on them ?
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing
On fre, 2010-07-16 at 14:13 +0300, Hannu Krosing wrote:
Should we put some externally managed languages , like pl/proxy also in
pgtemplate, so that CREATE LANGUAGE would work on them ?
This has been rejected several times before. See:
On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If we continue with the approach I took, we should implement the suggestion
to create a new data type for this in 9.1. That would be more waterproof than
the changes I made, if we introduce new ways to
On Jul 15, 2010, at 11:18 PM, Josh Berkus j...@agliodbs.com wrote:
I think it's very important, as Haas says, to consider that whatever we
do in this arena, we'll be living with it forever, so let's not make the
\dv vs. \df mistake again, ok?
Refresh my memory?
...Robert
--
Sent via
I have to agree with Simon here. \d is ridiculous for the common user.
+1
Regards
Markus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 16 July 2010 03:47, Robert Haas robertmh...@gmail.com wrote:
On Jul 15, 2010, at 11:58 AM, Brendan Jurd dire...@gmail.com wrote:
I dropped one thousand numerics with value zero into a table and
checked the on-disk size of the relation with your patch and on a
stock 8.4 instance. In both
Andrew Dunstan wrote:
Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so what non-psql interactive terminal programs are
there?
I think your assumption is
On 16/07/10 13:44, Brendan Jurd wrote:
pg_column_size() did return the results I was expecting.
pg_column_size(0::numeric) is 8 bytes on 8.4 and it's 6 bytes on HEAD
with your patch.
At this scale we should be seeing around 2 million bytes saved, but
instead the tables are identical. Is
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so what non-psql interactive terminal programs are
there?
2010/7/16 Bruce Momjian br...@momjian.us:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so what non-psql interactive terminal programs are
there?
On 16 July 2010 13:49, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so what
On 16 July 2010 22:51, Richard Huxton d...@archonet.com wrote:
On 16/07/10 13:44, Brendan Jurd wrote:
At this scale we should be seeing around 2 million bytes saved, but
instead the tables are identical. Is there some kind of disconnect in
how the new short numeric is making it to the disk,
On 16 July 2010 14:14, Brendan Jurd dire...@gmail.com wrote:
On 16 July 2010 22:51, Richard Huxton d...@archonet.com wrote:
On 16/07/10 13:44, Brendan Jurd wrote:
At this scale we should be seeing around 2 million bytes saved, but
instead the tables are identical. Is there some kind of
Tom Lane t...@sss.pgh.pa.us wrote:
* I didn't like this bit in cash_numeric():
result-n_sign_dscale = NUMERIC_SIGN(result) | fpoint;
Not only is that unwarranted chumminess with the implementation of
numeric, it's flat-out wrong. If the result isn't exactly the
right number of
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 13/07/10 21:36, Tom Lane wrote:
I wasn't terribly happy with that approach to begin with. I think we
need to rethink.
Do you want to go ahead with your plan of changing what's passed in
FuncInfo? I won't object if you want
Peter Eisentraut pete...@gmx.net wrote:
I didn't see any discussion about why this should return float8
rather than numeric. It seems wrong to use float8 for this.
That discussion took place several months ago on the -bugs list.
I'll paste some links from a quick search of the archives
Markus Wanner mar...@bluegap.ch wrote:
On 07/15/2010 10:37 PM, Alvaro Herrera wrote:
BTW I think this patch series makes sense, though I haven't
looked at it in detail. I guess it means I'll have to have a
look at the IMessages stuff as well.
Yes, only after adding these patches to the
On Jul 15, 2010, at 7:25 PM, Tom Lane wrote:
* I didn't like this bit in cash_numeric():
result-n_sign_dscale = NUMERIC_SIGN(result) | fpoint;
Not only is that unwarranted chumminess with the implementation of
numeric, it's flat-out wrong. If the result isn't exactly the right
Hi,
On 07/16/2010 04:01 PM, Kevin Grittner wrote:
Since these two patches were posted before the commit fest started,
and are prerequisites for six properly submitted patches, I'm going
with the spirit of the law and saying it's OK to add them. Does
the application allow that?
Yes, it does.
On 6 May 2010 04:42, Pavel Stehule pavel.steh...@gmail.com wrote:
attached patch contains to_string and to_array functions. These
functions are equivalent of array_to_string and string_to_array
function with maybe more correct NULL handling.
Hi Pavel,
I am reviewing your patch for the
Hi,
here's a review of the \sf and \ef [num] patch from
http://archives.postgresql.org/message-id/162867791003290927y3ca44051p80e697bc6b19d...@mail.gmail.com
== Formatting ==
The patch has some small tabs/spaces and whitespace issues and it
applies with some offsets, I ran pgindent and
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Peter Eisentraut pete...@gmx.net wrote:
I didn't see any discussion about why this should return float8
rather than numeric. It seems wrong to use float8 for this.
That discussion took place several months ago on the -bugs list.
I'll
Andy Balholm a...@balholm.com writes:
On Jul 15, 2010, at 7:25 PM, Tom Lane wrote:
* I didn't like this bit in cash_numeric():
result-n_sign_dscale = NUMERIC_SIGN(result) | fpoint;
Not only is that unwarranted chumminess with the implementation of
numeric, it's flat-out wrong. If the
Someone highlighed on IRC that after the first WHERE clause,
autocomplete no longer works.
An example:
CREATE TABLE tab_completion (
id serial,
stuff text,
meow boolean
);
SELECT * FROM tab_completion WHERE id = 2 AND stabtab
This would output a blank line.
Is there any chance of improving
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
* The cast functions were marked immutable, which is wrong because
they depend on the setting of lc_monetary. The right marking is
stable.
Is there any impact of the change to lc_monetary which would
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Someone highlighed on IRC that after the first WHERE clause,
autocomplete no longer works.
...
SELECT * FROM tab_completion WHERE id = 2 AND stabtab
...
Is there any chance of improving this so it would work for more than 1
WHERE clause?
Tom Lane t...@sss.pgh.pa.us wrote:
The only way I'd be willing to label those things immutable was if
we did something to lock down lc_monetary for the life of a
database (ie, make it work more like lc_collate does now). Which
might be a good idea, but it's not how it works today.
On Fri, 2010-07-16 at 14:07 +0100, Thom Brown wrote:
The problem is people are stating different requirements.
- to make it easy for new users of psql
- to simplify fetching basic database information from any client application
- to ease transition between MySQL and PostgreSQL
Close, but
On 16 July 2010 16:04, Greg Sabino Mullane g...@turnstep.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Someone highlighed on IRC that after the first WHERE clause,
autocomplete no longer works.
...
SELECT * FROM tab_completion WHERE id = 2 AND stabtab
...
Is there any
2010/7/13 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
Hi,
I've been working on writeable CTEs during the last couple of months, but
right now it looks like I'm going to miss the first commit fest for 9.1. I
was trying to make it work by expanding all wCTEs to their own Queries
during the
On Jul 16, 2010, at 8:11 AM, Simon Riggs wrote:
On Fri, 2010-07-16 at 14:07 +0100, Thom Brown wrote:
The problem is people are stating different requirements.
- to make it easy for new users of psql
- to simplify fetching basic database information from any client application
- to ease
On Fri, 2010-07-16 at 17:03 +0900, Fujii Masao wrote:
This commit changed XLogSetAsyncCommitLSN() so that it's called
for abort case. So we need to change the comment of the function
as follows:
Agreed, will fix.
Will also rename function to better document its new role.
New
On Thu, 2010-07-15 at 15:38 -0400, Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so what non-psql interactive terminal programs
are there?
My original thought was around the
Simon Riggs wrote:
On Thu, 2010-07-15 at 15:38 -0400, Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so what non-psql interactive terminal programs
are there?
My
On Fri, Jul 16, 2010 at 11:44:58AM -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Thu, 2010-07-15 at 15:38 -0400, Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so
On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
Sorry it's not relevant to the topic you post but ..
Relevant enough :-)
.. it seems you're
going to add new executor node called DtScanNode and let it hold
tuplestore passed by the Query indicated by index number. However, I
suppose there are
On Fri, 16 Jul 2010, Bruce Momjian wrote:
There are many tools that can access Postgres. Some are libpq programs,
though there are command line versions in every environment: java,
python, etc..
Yeah, but do enough people use them to warrant putting this in the
backend?
I may have lost the
On Jul 16, 2010, at 6:17 AM, Thom Brown wrote:
Joy! :) Nice patch Robert.
Indeed.
What are the implications for pg_upgrade? Will a database with values created
before the patch continue to work after the patch has been applied (as happened
with the new hstore in 9.0), or will pg_upgrade
Marc G. Fournier wrote:
On Fri, 16 Jul 2010, Bruce Momjian wrote:
There are many tools that can access Postgres. Some are libpq programs,
though there are command line versions in every environment: java,
python, etc..
Yeah, but do enough people use them to warrant putting this in the
David E. Wheeler wrote:
On Jul 16, 2010, at 6:17 AM, Thom Brown wrote:
Joy! :) Nice patch Robert.
Indeed.
What are the implications for pg_upgrade? Will a database with values
created before the patch continue to work after the patch has been
applied (as happened with the new hstore
On Jul 16, 2010, at 9:04 AM, Bruce Momjian wrote:
What are the implications for pg_upgrade? Will a database with values
created before the patch continue to work after the patch has been
applied (as happened with the new hstore in 9.0), or will pg_upgrade
need to be taught how to upgrade the
On Fri, Jul 16, 2010 at 12:04:01PM -0400, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Fri, 16 Jul 2010, Bruce Momjian wrote:
There are many tools that can access Postgres. Some are libpq programs,
though there are command line versions in every environment: java,
python, etc..
On Jul 16, 2010, at 9:09 AM, David Fetter wrote:
Clarification, do enough people use non-psql command line tools to
warrant putting this in the backend?
Yes. Such backend stuff is in every RDBMS except ours.
I admit that I had to do a *lot* of work to write the schema-testing functions
Hello
2010/7/16 Brendan Jurd dire...@gmail.com:
On 6 May 2010 04:42, Pavel Stehule pavel.steh...@gmail.com wrote:
attached patch contains to_string and to_array functions. These
functions are equivalent of array_to_string and string_to_array
function with maybe more correct NULL handling.
2010/7/17 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
is exsiting one that work with single tuplestore, it might be sane to
modify this so that it accepts tuplestore from
David Fetter wrote:
On Fri, Jul 16, 2010 at 12:04:01PM -0400, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Fri, 16 Jul 2010, Bruce Momjian wrote:
There are many tools that can access Postgres. Some are libpq programs,
though there are command line versions in every
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
The only way I'd be willing to label those things immutable was if
we did something to lock down lc_monetary for the life of a
database (ie, make it work more like lc_collate does now). Which
might be a
On Fri, 2010-07-16 at 12:16 -0400, Bruce Momjian wrote:
Really? What are the other syntaxes?
SHOW TABLES
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
* Simon Riggs si...@2ndquadrant.com [100716 12:24]:
On Fri, 2010-07-16 at 12:16 -0400, Bruce Momjian wrote:
Really? What are the other syntaxes?
SHOW TABLES
Obviously, only for some $value of $other...
The 3 database I have access to:
[DataDirect][ODBC SQL Server Driver][SQL
Simon Riggs wrote:
On Fri, 2010-07-16 at 12:16 -0400, Bruce Momjian wrote:
Really? What are the other syntaxes?
SHOW TABLES
That is MySQL? Do does every other RDBMs also use that, as David
suggested?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On 7/16/10 7:15 PM +0300, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkajamarko.tiikk...@cs.helsinki.fi:
I thought about this, but I don't necessarily like the idea of overloading
executor nodes.
Neither do I have good shape for this solution. Maybe it's not good
idea. But my concern is adding
Bruce Momjian br...@momjian.us wrote:
What are the other syntaxes?
For Sybase ASE sp_help and other stored procedures, see:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36273.1550/html/sprocs/X85190.htm
Like \d, these server-side stored procedures can return
On Fri, 2010-07-16 at 12:25 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2010-07-16 at 12:16 -0400, Bruce Momjian wrote:
Really? What are the other syntaxes?
SHOW TABLES
That is MySQL? Do does every other RDBMs also use that, as David
suggested?
He didn't say it was
On 17 July 2010 02:15, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/16 Brendan Jurd dire...@gmail.com:
Regarding the behaviour of the third argument (null_string), I was a
little surprised by the results when I passed in a NULL.
I didn't thinking about NULL as separator before.
Peter Eisentraut pete...@gmx.net writes:
On fre, 2010-07-16 at 14:13 +0300, Hannu Krosing wrote:
Should we put some externally managed languages , like pl/proxy also in
pgtemplate, so that CREATE LANGUAGE would work on them ?
This has been rejected several times before. See:
Robert Haas robertmh...@gmail.com writes:
On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If we continue with the approach I took, we should implement the suggestion
to create a new data type for this in 9.1. That would be more waterproof
than the
On Jul 16, 2010, at 7:43 AM, Bruce Momjian br...@momjian.us wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I assume SHOW TABLES would only be useful for interactive terminal
sesssions, not for application code (which should use
information_schema), so what non-psql interactive terminal
2010/7/16 Brendan Jurd dire...@gmail.com:
On 16 July 2010 03:47, Robert Haas robertmh...@gmail.com wrote:
You might also look at testing with pg_column_size().
pg_column_size() did return the results I was expecting.
pg_column_size(0::numeric) is 8 bytes on 8.4 and it's 6 bytes on HEAD
with
Excerpts from Tom Lane's message of vie jul 16 12:49:25 -0400 2010:
Peter Eisentraut pete...@gmx.net writes:
On fre, 2010-07-16 at 14:13 +0300, Hannu Krosing wrote:
Should we put some externally managed languages , like pl/proxy also in
pgtemplate, so that CREATE LANGUAGE would work on them
Greg Sabino Mullane g...@turnstep.com writes:
No: there is only a small number of words that we go back through,
so the above will not work as we cannot get back to the name of the table
from the right side of the AND. The way to fix that is to redesign our
tab-completion system such that
On Fri, Jul 16, 2010 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote:
For committers.
Perhaps this discussions should be moved to the General list in order
to poll the userbase.
My .02 is that SHOW commands (even if they are not compatible) would
make it much easier for me to make an
On Fri, 16 Jul 2010, Simon Riggs wrote:
SQLServer and Sybase use sp_ procedures for this
Haven't experienced Sybase for 2 years in my last job, I can tell you that
the sp_* commands are definitely non-intuitive :(
Marc G. FournierHub.Org Hosting Solutions S.A.
This is a review of the phypot - Pygmy Hippotause patch:
http://archives.postgresql.org/message-id/4a9897e1.8090...@netspace.net.au
submitted by Paul Matthews.
Contents Purpose
==
The purpose of the patch is to compute a hypotenuse with higher
precision than the current
si...@2ndquadrant.com (Simon Riggs) writes:
Just for the record, I've never ever met anyone that said Oh, this
\d syntax makes so much sense. I'm a real convert to Postgres now
you've shown me this. The reaction is always the opposite one;
always negative. Which detracts from our efforts
Le 16 juil. 2010 à 12:43, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com a écrit :
On 16/07/10 10:40, Fujii Masao wrote:
So we should always prevent the standby from applying any WAL in pg_xlog
unless walreceiver is in progress. That is, if there is no WAL available
in the archive,
Marc G. Fournier scra...@hub.org wrote:
Haven't experienced Sybase for 2 years in my last job, I can tell
you that the sp_* commands are definitely non-intuitive :(
In general, I'd agree; although I think I got used to them about as
fast as the PostgreSQL backslash commands. In the
Chris Browne wrote:
- I'd sure like to be able to write queries that *don't* involve
array smashing or using grep on \z output to analyze object
permissions.
The \z output is an embarrassment, no question about it in my mind.
--
Bruce Momjian br...@momjian.us
On 16/07/10 20:11, Rob Wultsch wrote:
On Fri, Jul 16, 2010 at 9:56 AM, Robert Haasrobertmh...@gmail.com wrote:
For committers.
Perhaps this discussions should be moved to the General list in order
to poll the userbase.
My .02 is that SHOW commands (even if they are not compatible) would
Le 16 juil. 2010 à 13:13, Hannu Krosing ha...@2ndquadrant.com a écrit :
Hi
Should we put some externally managed languages , like pl/proxy also in
pgtemplate, so that CREATE LANGUAGE would work on them ?
I still to manage an extension patch. It should be easy for plproxy author (hi
Marko)
On 16/07/10 20:26, Dimitri Fontaine wrote:
Le 16 juil. 2010 à 12:43, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com a écrit :
On 16/07/10 10:40, Fujii Masao wrote:
So we should always prevent the standby from applying any WAL in pg_xlog
unless walreceiver is in progress. That is, if
On 14/07/10 09:50, Fujii Masao wrote:
TODO
The patch have no features for performance improvement of synchronous
replication. I admit that currently the performance overhead in the
master is terrible. We need to address the following TODO items in the
subsequent CF.
* Change the poll loop
On Fri, Jul 16, 2010 at 10:52 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 16/07/10 20:11, Rob Wultsch wrote:
On Fri, Jul 16, 2010 at 9:56 AM, Robert Haasrobertmh...@gmail.com
wrote:
For committers.
Perhaps this discussions should be moved to the General list in
On Fri, 2010-07-16 at 20:52 +0300, Heikki Linnakangas wrote:
On 16/07/10 20:11, Rob Wultsch wrote:
On Fri, Jul 16, 2010 at 9:56 AM, Robert Haasrobertmh...@gmail.com wrote:
For committers.
Perhaps this discussions should be moved to the General list in order
to poll the userbase.
My
Robert Haas robertmh...@gmail.com writes:
I'm not entirely happy with the way I handled the variable-length
struct, although I don't think it's horrible, either. I'm willing to
rework it if someone has a better idea.
I don't like the way you did that either (specifically, not the kluge
in
2010/7/16 Brendan Jurd dire...@gmail.com:
On 17 July 2010 02:15, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/16 Brendan Jurd dire...@gmail.com:
Regarding the behaviour of the third argument (null_string), I was a
little surprised by the results when I passed in a NULL.
I didn't
Hi Simon,
Your patch implements part of a feature I desire greatly - thanks!
Some comments:
On Thursday 15 July 2010 11:24:27 Simon Riggs wrote:
! LOCKMODE
! AlterTableGreatestLockLevel(List *cmds)
! {
!ListCell *lcmd;
!LOCKMODE lockmode = ShareUpdateExclusiveLock; /* default
Hello
I have a one idea nonstandard enhancing of sprintf - relatie often job
is a quoting in PostgreSQL. So sprintf should have a special formats
for quoted values. What do you think about
%lq ... literal quoted
%iq ... ident quoted
??
Regards
Pavel
2010/7/13 Pavel Stehule
On Friday 16 July 2010 20:41:44 Andres Freund wrote:
! */
!case AT_AddColumn: /* may
rewrite heap, in some cases and visible to SELECT */ !
case AT_DropColumn: /* change
visible to SELECT
On Fri, 2010-07-16 at 20:41 +0200, Andres Freund wrote:
You argue above that you cant change SET [NOT] NULL to be less
restrictive because it might change plans - isnt that true for some of the
above cases as well?
For example UNIQUE/PRIMARY might make join removal possible - which could
On Fri, 2010-07-16 at 21:10 +0200, Andres Freund wrote:
On Friday 16 July 2010 20:41:44 Andres Freund wrote:
! */
!case AT_AddColumn: /* may
rewrite heap, in some cases and visible to SELECT */ !
case
On 16/07/10 21:32, Simon Riggs wrote:
On Fri, 2010-07-16 at 20:52 +0300, Heikki Linnakangas wrote:
I have nothing against SHOW TABLES
...but SHOW wins, based on numbers of people expecting that
I'm not sure I buy that, but even if it's true, it doesn't seem fair to
do a favor to one group
On 17 July 2010 04:52, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/7/16 Brendan Jurd dire...@gmail.com:
Also, if we're going to make the function non-strict, we need to
consider how to respond when the user specifies NULL for the other
arguments. If the field separator is NULL, bearing
On 16/07/10 11:13, Fujii Masao wrote:
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masaomasao.fu...@gmail.com wrote:
Thanks for reminding me. I attached the updated patch.
This patch left uncommitted for half a month. No one is interested in
the patch?
Sorry for the lack of interest ;-)
The
On Friday 16 July 2010 21:12:33 Simon Riggs wrote:
On Fri, 2010-07-16 at 20:41 +0200, Andres Freund wrote:
You argue above that you cant change SET [NOT] NULL to be less
restrictive because it might change plans - isnt that true for some of
the above cases as well?
For example
On Friday 16 July 2010 21:15:44 Simon Riggs wrote:
On Fri, 2010-07-16 at 21:10 +0200, Andres Freund wrote:
On Friday 16 July 2010 20:41:44 Andres Freund wrote:
! */
!case AT_AddColumn: /* may
rewrite heap, in some cases
On Fri, 2010-07-16 at 21:38 +0200, Andres Freund wrote:
boom
Your test case would still occur in the case where the first query had
not been executed against the same table. So the test case illustrates a
failing of join removal, not of this patch.
--
Simon Riggs www.2ndQuadrant.com
1 - 100 of 118 matches
Mail list logo
