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 requi
On 13/07/10 21:36, Tom Lane wrote:
Dave Page 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)
FROM pg_proc pr
On Thu, Jul 15, 2010 at 12:16 AM, Robert Haas wrote:
> On Wed, Jul 14, 2010 at 2:50 AM, Fujii Masao wrote:
>> 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
On Jul 15, 2010, at 6:43 PM, Magnus Hagander wrote:
> On Thu, Jul 15, 2010 at 18:35, Simon Riggs 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 are many
On Mon, May 31, 2010 at 8:48 PM, Simon Riggs wrote:
> On Mon, 2010-05-31 at 20:11 +0900, Fujii Masao wrote:
>> On Thu, May 13, 2010 at 8:39 PM, Simon Riggs wrote:
>> > Log Message:
>> > ---
>> > Ensure that top level aborts call XLogSetAsyncCommit(). Not doing
>> > so simply leads to data
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masao 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 checkpoint_segments parameter
On Tue, Jul 6, 2010 at 9:59 AM, Takahiro Itagaki
wrote:
>
> Tom Lane 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 of relcache flush.
>
> Relcache will be
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 fact
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 pla
Tom Lane wrote:
> Itagaki Takahiro 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 lily-gilding
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 c
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 à l'Universit
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 l
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:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg00
On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
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 call functions in the future.
T
On Jul 15, 2010, at 11:18 PM, Josh Berkus 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 pgsql-hackers mailing
> 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 wrote:
> On Jul 15, 2010, at 11:58 AM, Brendan Jurd 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 cases the result was exactly the s
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 ass
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 ther
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
> > > th
2010/7/16 Bruce Momjian :
> 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 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 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, or perhaps
On 16 July 2010 14:14, Brendan Jurd wrote:
> On 16 July 2010 22:51, Richard Huxton 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 s
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 number of digits (say,
Heikki Linnakangas 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 to do it, but I wouldn't feel
Peter Eisentraut 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 below.
Since mul
Markus Wanner 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 commit fes
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 righ
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
On 6 May 2010 04:42, Pavel Stehule 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 commitfest.
Overall the pat
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 rebase
"Kevin Grittner" writes:
> Peter Eisentraut 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 o
Andy Balholm 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 result
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 s
This would output a blank line.
Is there any chance of improving this so i
"Kevin Grittner" writes:
> Tom Lane 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 matter
> besides the number of decimal
-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 s
...
> Is there any chance of improving this so it would work for more than 1
> WHERE clause? I
Tom Lane 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.
Interesting. In gener
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,
On 16 July 2010 16:04, Greg Sabino Mullane 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 s
> ...
>> Is there any chance of i
2010/7/13 Marko Tiikkaja :
> 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 rewrite stage (a very
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
>>
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 r
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 th
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?
>
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
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 o
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 g
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 nee
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 putti
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 ne
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 upgra
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,
> > >>
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 function
Hello
2010/7/16 Brendan Jurd :
> On 6 May 2010 04:42, Pavel Stehule 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
2010/7/17 Marko Tiikkaja :
> 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 Query instead of its
>>
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
"Kevin Grittner" writes:
> Tom Lane 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 t
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 [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 Server]Could not f
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 http://momjian.us
EnterpriseDB
On 7/16/10 7:15 PM +0300, Hitoshi Harada wrote:
2010/7/17 Marko Tiikkaja:
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 DtScanNode, which looks simila
Bruce Momjian 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 a number of
resu
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
On 17 July 2010 02:15, Pavel Stehule wrote:
> 2010/7/16 Brendan Jurd :
>> 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. Current behave isn't
> practical. When
Peter Eisentraut 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:
> http://archives.postgres
Robert Haas writes:
> On Jul 16, 2010, at 2:27 AM, Heikki Linnakangas
> 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 call
On Jul 16, 2010, at 7:43 AM, 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 prog
2010/7/16 Brendan Jurd :
> On 16 July 2010 03:47, Robert Haas 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 your patch.
>
> However, even
Excerpts from Tom Lane's message of vie jul 16 12:49:25 -0400 2010:
> Peter Eisentraut 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" 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 it knows abou
On Fri, Jul 16, 2010 at 9:56 AM, Robert Haas 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 argument to my boss to at l
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.
s
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 implement
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
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, the standby ignores pg_xlog an
"Marc G. Fournier" 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 particular case
of s
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 http://momjian.
On 16/07/10 20:11, Rob Wultsch wrote:
On Fri, Jul 16, 2010 at 9:56 AM, Robert Haas 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 m
Le 16 juil. 2010 à 13:13, Hannu Krosing 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) to care for pltem
On 16/07/10 20:26, Dimitri Fontaine wrote:
Le 16 juil. 2010 à 12:43, Heikki
Linnakangas 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 arc
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 i
On Fri, Jul 16, 2010 at 10:52 AM, Heikki Linnakangas
wrote:
> On 16/07/10 20:11, Rob Wultsch wrote:
>>
>> On Fri, Jul 16, 2010 at 9:56 AM, Robert Haas
>> wrote:
>>>
>>> For committers.
>>
>> Perhaps this discussions should be moved to the General list in order
>> to poll the userbase.
>>
>> My .0
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 Haas wrote:
> >> For committers.
> >
> > Perhaps this discussions should be moved to the General list in order
> > to poll the userbase.
> >
> > My .02 i
Robert Haas 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 NUMERIC_DIGITS()). It
2010/7/16 Brendan Jurd :
> On 17 July 2010 02:15, Pavel Stehule wrote:
>> 2010/7/16 Brendan Jurd :
>>> 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. Curre
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; /* d
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 :
> Hello
>
> 2010/
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
> >> visi
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 cou
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 */ !
> > >>
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 o
On 17 July 2010 04:52, Pavel Stehule wrote:
> 2010/7/16 Brendan Jurd :
>> 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 in mind that NULL
>> can't match a
On 16/07/10 11:13, Fujii Masao wrote:
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masao 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 patch adds the document a
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 exampl
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,
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
Simon Riggs wrote:
> [...]
> Light switches are usually at shoulder height next to a door. Our light
> switches are 2 metres up, on the far side of the room. People are sick
> of banging their knees on furniture while trying to grope for the light.
> The light switch isn't so much hard to use, it
Daniel Farina writes:
> Generally I think the delimited untoasting of metadata from arrays
> separately from the payload is Not A Bad Idea.
I looked at this patch a bit. I agree that it could be a big win for
large external arrays, but ...
1. As-is, it's a significant *pessimization* for small
1 - 100 of 116 matches
Mail list logo
