On Fri, Jun 25, 2010 at 14:06, Peter Eisentraut wrote:
> Second version:
Hi!
Ive looked this over. Looks great! I have some nits about the
documentation and comments ( non issues like referencing primary keys
when it really means not null unique indexes :-P ), but on the whole
it works and loo
* Robert Haas (robertmh...@gmail.com) wrote:
> Why must the backslash commands be more powerful than any alternative
> we might come up with?
Because they encode alot of information in a character- something which
is next to impossible to do in "english".
Consider 'standard' perl vs. perl w/ 'use
On Fri, Jul 16, 2010 at 1:52 PM, Heikki Linnakangas
wrote:
> That's for MySQL. I come from a DB2 background, and when I started using
> psql years ago, I often typed "LIST TABLES" without thinking much about it.
> Not SHOW TABLES, but LIST TABLES.
>
> I bet Oracle users coming to PostgreSQL will t
Andres Freund writes:
> Just to help me: The primary reasons for using SnapshotNow is speed and in
> some cases correctness (referential integrity). Right? Any other reasons?
Well, the main point for system catalog accesses is that you *must* have
an up-to-date view of the table schemas. As an
"Kevin Grittner" wrote:
>>> postgres=# SHOW ME THE MONEY;
>>> WARNING: THE MONEY is deprecated in this version of Postgres and
>>> may be discarded in a future version
>>> HINT: Use SHOW ME THE NUMERIC with the desired precision instead.
>> Funny, but no longer true:
>> http://www.postgresql.o
On Saturday 17 July 2010 01:53:24 Robert Haas wrote:
> On Jul 16, 2010, at 6:01 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> What could the join removal path (and similar places) *possibly* do
> >> against such a case? Without stopping to use SnapshotNow I dont see any
> >> way :-(
> >
> >
On Jul 16, 2010, at 6:01 PM, Tom Lane wrote:
> Andres Freund writes:
>> What could the join removal path (and similar places) *possibly* do against
>> such a case? Without stopping to use SnapshotNow I dont see any way :-(
>
> But the planner, along with most of the rest of the backend, *does*
Andres Freund writes:
> What could the join removal path (and similar places) *possibly* do against
> such a case? Without stopping to use SnapshotNow I dont see any way :-(
But the planner, along with most of the rest of the backend, *does* use
SnapshotNow when examining the system catalogs.
I
Le 16 juil. 2010 à 18:42, Kevin Grittner a écrit :
> Like \d, these server-side stored procedures can return a number of
> result sets. Like Robert, I'm skeptical of implementing a
> server-side solution for PostgreSQL which doesn't do the same. I'm
> not clear on whether that's even possible wit
Martin Pihlak writes:
> Thanks, somehow I missed that we can already specify octal integers
> as GUC-s. I now converted the log_file_mode to integer and dropped
> the assign_log_file_mode function.
Applied with a few corrections. The noncosmetic changes were:
* prevent Log_file_mode from disabl
"Joshua D. Drake" wrote:
> On Sat, 2010-07-17 at 07:36 +1000, Brendan Jurd wrote:
>> postgres=# SHOW ME THE MONEY;
>> WARNING: THE MONEY is deprecated in this version of Postgres and
>> may be discarded in a future version
>> HINT: Use SHOW ME THE NUMERIC with the desired precision instead.
>
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> 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 of users, leaving the rest stranded and excluded
> forever. Even if SHOW TABLES has a bigger mind-share than the others,
> sure
On Sat, 2010-07-17 at 07:36 +1000, Brendan Jurd wrote:
> On 17 July 2010 07:26, Joshua D. Drake wrote:
> > Yes. We should provide a single, well described grammar for interacting
> > with objects in the database regardless of client. I should be able to
> > open ANY SQL terminal, and type SHOW ME
On 17 July 2010 07:26, Joshua D. Drake wrote:
> Yes. We should provide a single, well described grammar for interacting
> with objects in the database regardless of client. I should be able to
> open ANY SQL terminal, and type SHOW ME THE MONEY and have Benjamins
> fall out.
postgres=# SHOW ME TH
On Fri, 2010-07-16 at 19:32 +0100, Simon Riggs wrote:
> That's a very sensible suggestion, we should give a hint for all common
> commands SHOW, LIST, etc., even though we pick just one to implement.
>
> > That way we're not on the hook to maintain them forever, and we
> > will be
>
> > doing
On Friday 16 July 2010 22:24:32 Simon Riggs wrote:
> 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
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
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
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
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 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 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 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 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 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 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 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
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/
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
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
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
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
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 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 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
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: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
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.
"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
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
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
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
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
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
"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
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 ?
>
>
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
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
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
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
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
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
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 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
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
* 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
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
"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
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
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
>>
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
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
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: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
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
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
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
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 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, 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
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 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
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 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
>>
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 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
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,
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
-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
"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
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
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
"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
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
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,
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 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
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
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
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
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,
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
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 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
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?
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
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
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 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
> 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
1 - 100 of 116 matches
Mail list logo
