In response to Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com writes:
postgres=# select '1e+01'::Integer
postgres-# ;
ERROR: invalid input syntax for integer: 1e+01
I have never heard of any programming system anywhere that accepts such
a syntax for integers (assuming it
Bill Moran wmo...@potentialtech.com writes:
In response to Tom Lane t...@sss.pgh.pa.us:
I have never heard of any programming system anywhere that accepts such
a syntax for integers (assuming it distinguishes integers from other
numbers at all). I'm not excited about being the first.
But
On Fri, 2010-12-17 at 14:35 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
postgres=# select '1e+01'::Integer
postgres-# ;
ERROR: invalid input syntax for integer: 1e+01
I have never heard of any programming system anywhere that accepts
such
a syntax for integers
Joshua D. Drake j...@commandprompt.com writes:
On Fri, 2010-12-17 at 14:35 -0500, Tom Lane wrote:
I have never heard of any programming system anywhere that accepts
such
a syntax for integers (assuming it distinguishes integers from other
numbers at all).
Python 2.6.6 (r266:84292, Sep 15
print int(1e+01)
10
That isn't building an integer: it is creating a float and casting to an int.
try:
int( 1e100 )
Best,
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Just another example of the fact that PHP was designed by incompetent
amateurs :-(
http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html
Unless I am misunderstanding the argument... perl and python both
support what is suggested here.
j...@jd-desktop:~$ perl -e 'print
On Fri, Dec 17, 2010 at 3:31 PM, Joshua D. Drake j...@commandprompt.com wrote:
Just another example of the fact that PHP was designed by incompetent
amateurs :-(
http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html
Unless I am misunderstanding the argument... perl and
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type help, copyright, credits or license for more information.
isinstance(10,int)
True
isinstance(1e10,int)
False
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing
Christophe Pettus x...@thebuild.com writes:
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type help, copyright, credits or license for more information.
isinstance(10,int)
True
isinstance(1e10,int)
False
Right. Possibly a more concrete
On Fri, Dec 17, 2010 at 12:16 PM, Bill Moran wmo...@potentialtech.com wrote:
In response to Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com writes:
postgres=# select '1e+01'::Integer
postgres-# ;
ERROR: invalid input syntax for integer: 1e+01
I have never heard of any
In response to Joshua D. Drake j...@commandprompt.com:
Just another example of the fact that PHP was designed by incompetent
amateurs :-(
http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html
Unless I am misunderstanding the argument... perl and python both
Hi,
I've read about 10 papers about estimation this week, and I have gained
some insight. I'm not going to describe each of the papers here, I plan
to set up a wiki page about cross column statistics
http://wiki.postgresql.org/wiki/Cross_Columns_Stats
and I'll put the list of papers and some
On Fri, Dec 17, 2010 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. I think that BM_UNLOGGED might be a poor choice for the flag name,
just because it overstates what the bufmgr
In response to Jeff Janes jeff.ja...@gmail.com:
On Fri, Dec 17, 2010 at 12:16 PM, Bill Moran wmo...@potentialtech.com wrote:
In response to Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com writes:
postgres=# select '1e+01'::Integer
postgres-# ;
ERROR: invalid input
Here is a small patch that allows casting a table's row type to the
table's supertype if it's a typed table. This is analogous to the
existing facility that allows casting a row type to a supertable's row
type.
diff --git i/src/backend/parser/parse_coerce.c w/src/backend/parser/parse_coerce.c
Dne 17.12.2010 19:58, Robert Haas napsal(a):
I haven't read the paper yet (sorry) but just off the top of my head,
one possible problem here is that our n_distinct estimates aren't
always very accurate, especially for large tables. As we've discussed
before, making them accurate requires
Robert Haas robertmh...@gmail.com writes:
Allright, what do you want to call the other bit, then? BM_SKIP_XLOG_FLUSH?
Like I said, I'd be tempted to invert the sense, so that the flag is set
for normal relations. Then it becomes something like BM_FLUSH_XLOG.
regards,
[ hit send too soon ... ]
Robert Haas robertmh...@gmail.com writes:
Since these bits will only be set/cleared when the buffer mapping is
changed, can we examine this bit without taking the spinlock?
Only if you're willing for the result to be unreliable. In the
case of the xlog flush bit, I
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
I noticed that the fastpath code doesn't update ps_status, which would
be harmless except that it leads to idle in transaction being logged
in log_line_prefix for the command
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
Hm, what about pgstat_report_activity()?
Just noticed that it's already handled in postgres.c, before calling
HandleFunctionRequest. Probably not worth messing with.
Ah.
Tomas Vondra t...@fuzzy.cz writes:
AFAIK it will work with reasonably precise estimates, but the point is
you need an estimate of distinct values of the whole group of columns.
So when you want to get an estimate for queries on columns (a,b), you
need the number of distinct value combinations
On 17.12.2010 23:13, Tomas Vondra wrote:
Dne 17.12.2010 19:58, Robert Haas napsal(a):
I haven't read the paper yet (sorry) but just off the top of my head,
one possible problem here is that our n_distinct estimates aren't
always very accurate, especially for large tables. As we've discussed
Dne 17.12.2010 22:24, Tom Lane napsal(a):
That seems likely to be even more unreliable than our existing
single-column estimates :-(
regards, tom lane
Well, yes :-(
I guess this is a place where we could use a multi-column index, if it
contains all the interesting
Excerpts from Tom Lane's message of vie dic 17 18:21:48 -0300 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
Hm, what about pgstat_report_activity()?
Just noticed that it's already handled in postgres.c, before
On 12/17/10 12:46 PM, Jeff Janes wrote:
And so does:
SELECT 1.23e+01::Integer
which I find just as dangerous as
SELECT '1.234e+01'::Integer;
Add quotes to either of the other two, and then they don't work either.
Well, that's stupidly arbitrary. If we're not going to accept
Dne 17.12.2010 22:41, Heikki Linnakangas napsal(a):
On 17.12.2010 23:13, Tomas Vondra wrote:
Dne 17.12.2010 19:58, Robert Haas napsal(a):
I haven't read the paper yet (sorry) but just off the top of my head,
one possible problem here is that our n_distinct estimates aren't
always very
I have often found myself wanting that psql automatically switch between
normal and \x mode depending on the width of the output. Would others
find this useful?
Attached is a crude demo patch. Enable with \pset expanded auto.
diff --git i/src/bin/psql/command.c w/src/bin/psql/command.c
index
Josh Berkus j...@agliodbs.com writes:
On 12/17/10 12:46 PM, Jeff Janes wrote:
Add quotes to either of the other two, and then they don't work either.
Well, that's stupidly arbitrary. If we're not going to accept
'1.234e+01'::Integer, then we shouldn't accept 1.234e+01::Integer either.
It's
On Sat, Dec 18, 2010 at 00:05, Josh Berkus j...@agliodbs.com wrote:
Well, that's stupidly arbitrary. If we're not going to accept
'1.234e+01'::Integer, then we shouldn't accept 1.234e+01::Integer either.
Not surprising to me. This is how many languages implement type conversion.
Python:
And so does:
SELECT 1.23e+01::Integer
which I find just as dangerous as
SELECT '1.234e+01'::Integer;
Add quotes to either of the other two, and then they don't work either.
Well, that's stupidly arbitrary. If we're not going to accept
'1.234e+01'::Integer, then we shouldn't
Well, that's stupidly arbitrary. If we're not going to accept
'1.234e+01'::Integer, then we shouldn't accept 1.234e+01::Integer either.
It's not arbitrary in the slightest. One is a run-time type conversion;
the other is a question of what strings the type-specific input routine
for
On Fri, Dec 17, 2010 at 6:09 PM, Josh Berkus j...@agliodbs.com wrote:
Oh, *I* understand the difference. Any app developer is going to see it
as stupidly arbitrary, though.
Speaking as someone who spent 9 years doing app development, I dispute
the word any.
--
Robert Haas
EnterpriseDB:
On my new Mingw setup, the following makefile fails:
foo := $(shell pwd -W)
all:
@echo foo: $(foo)
with output looking like:
pwd: invalid option -- W
Try `pwd --help' for more information.
foo:
while the following works:
foo := $(shell sh -c pwd -W)
all:
On 12/17/10 3:34 PM, Robert Haas wrote:
On Fri, Dec 17, 2010 at 6:09 PM, Josh Berkus j...@agliodbs.com wrote:
Oh, *I* understand the difference. Any app developer is going to see it
as stupidly arbitrary, though.
Speaking as someone who spent 9 years doing app development, I dispute
the
On Fri, Dec 17, 2010 at 6:49 PM, Josh Berkus j...@agliodbs.com wrote:
On 12/17/10 3:34 PM, Robert Haas wrote:
On Fri, Dec 17, 2010 at 6:09 PM, Josh Berkus j...@agliodbs.com wrote:
Oh, *I* understand the difference. Any app developer is going to see it
as stupidly arbitrary, though.
Speaking
pete...@gmx.net (Peter Eisentraut) writes:
I have often found myself wanting that psql automatically switch between
normal and \x mode depending on the width of the output. Would others
find this useful?
I haven't tested the patch, but that *does* sound generally useful.
It's no fun trying to
On 12/17/2010 07:03 PM, Robert Haas wrote:
If it's not a good idea to enable that functionality,
then it would be nice to come up with some way to make it more clear why
it's failing.
I guess I'm about to show my arrogance and utter lack of sympathy for
the common man here, but it's hard
Well, maybe. Also, giving the sort of feedback Josh seems to want
probably would not be nearly as easy as he seems to think, ISTM.
Oh, I don't think it would be easy. I can't think, right now, of a good
way to do it.
--
-- Josh Berkus
On Dec 16, 2010, at 8:39 PM, Alex Hunsaker wrote:
No, URI::Escape is fine. The issue is that if you don't decode text to
Perl's internal form, it assumes that it's Latin-1.
So... you are saying \xc3\xa9 eq \xe9 or chr(233) ?
Not knowing what those mean, I'm not saying either one, to my
On Dec 17, 2010, at 5:04 PM, David E. Wheeler wrote:
see? Either uri_unescape() should be decoding that utf8() or you need
to do it *after* you call uri_unescape(). Hence the maybe it could be
considered a bug in uri_unescape().
Agreed.
On second thought, no. You can in fact encode
Hi,
It has annoys me every time I want to move a table to another schema
that it completes to SET SCHEMA TO DEFAULT after a couple of presses of
the tab key. So today I decided to get off my lazy ass to write a tiny
patch to fix this behaviour. :)
My first patch for PostgreSQL so a question:
On Fri, Dec 17, 2010 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Since these bits will only be set/cleared when the buffer mapping is
changed, can we examine this bit without taking the spinlock?
Only if you're willing for the result to be unreliable.
If we read the bits while someone else
On Fri, Dec 17, 2010 at 8:34 PM, andreas andr...@proxel.se wrote:
It has annoys me every time I want to move a table to another schema
that it completes to SET SCHEMA TO DEFAULT after a couple of presses of
the tab key. So today I decided to get off my lazy ass to write a tiny
patch to fix
On Fri, Dec 17, 2010 at 7:35 PM, Josh Berkus j...@agliodbs.com wrote:
Well, maybe. Also, giving the sort of feedback Josh seems to want
probably would not be nearly as easy as he seems to think, ISTM.
Oh, I don't think it would be easy. I can't think, right now, of a good
way to do it.
I
Ah, sorry forgot the most important part of my explanation.
What it does is gets rid of the incorrect completion which comes from
the completion rule for SET foo TO bar by adding the correct
completion for SET SCHEMA higher up in the completion function.
So instead of an incorrect completion we
On Fri, Dec 17, 2010 at 9:14 PM, Andreas Karlsson andr...@proxel.se wrote:
Ah, sorry forgot the most important part of my explanation.
What it does is gets rid of the incorrect completion which comes from
the completion rule for SET foo TO bar by adding the correct
completion for SET SCHEMA
On Fri, 2010-12-17 at 21:20 -0500, Robert Haas wrote:
On Fri, Dec 17, 2010 at 9:14 PM, Andreas Karlsson andr...@proxel.se wrote:
What it does is gets rid of the incorrect completion which comes from
the completion rule for SET foo TO bar by adding the correct
completion for SET SCHEMA
On Fri, Dec 17, 2010 at 9:30 PM, Andreas Karlsson andr...@proxel.se wrote:
On Fri, 2010-12-17 at 21:20 -0500, Robert Haas wrote:
On Fri, Dec 17, 2010 at 9:14 PM, Andreas Karlsson andr...@proxel.se wrote:
What it does is gets rid of the incorrect completion which comes from
the completion
Sorry, everyone.
Ignore my patch. This was already fixed in HEAD and while I wrote my
patch for the HEAD I somehow failed to spot that it was already fixed
when testing without my patch.
Nice that is fixed, and sorry for the noise.
Andreas
--
Sent via pgsql-hackers mailing list
On Fri, Dec 17, 2010 at 9:47 PM, Andreas Karlsson andr...@proxel.se wrote:
Sorry, everyone.
Ignore my patch. This was already fixed in HEAD and while I wrote my
patch for the HEAD I somehow failed to spot that it was already fixed
when testing without my patch.
Nice that is fixed, and sorry
On Fri, Dec 17, 2010 at 11:49, Shigeru HANADA han...@metrosystems.co.jp wrote:
I've just moved permission check and read-only check from BeginCopy()
to DoCopy(). Please see attached patch.
Thanks!
Are there any objections for the change? If acceptable,
I'd like to apply it prior to SQL/MED
On Sat, Dec 18, 2010 at 07:12, Peter Eisentraut pete...@gmx.net wrote:
I have often found myself wanting that psql automatically switch between
normal and \x mode depending on the width of the output. Would others
find this useful?
+1
Attached is a crude demo patch. Enable with \pset
Here's an attempt to summarize the remaining issues with this patch
that I know about. I may have forgotten something, so please mention
it if you notice something missing.
1. pg_dump needs an option to control whether unlogged tables are
dumped. --no-unlogged-tables seems like the obvious
On Dec 17, 2010, at 7:04 PM, David E. Wheeler wrote:
On Dec 16, 2010, at 8:39 PM, Alex Hunsaker wrote:
No, URI::Escape is fine. The issue is that if you don't decode text to
Perl's internal form, it assumes that it's Latin-1.
So... you are saying \xc3\xa9 eq \xe9 or chr(233) ?
Not
On Dec17, 2010, at 23:12 , Tomas Vondra wrote:
Well, not really - I haven't done any experiments with it. For two
columns selectivity equation is
(dist(A) * sel(A) + dist(B) * sel(B)) / (2 * dist(A,B))
where A and B are columns, dist(X) is number of distinct values in
column X and
On Fri, Dec 17, 2010 at 18:22, David E. Wheeler da...@kineticode.com wrote:
On Dec 17, 2010, at 5:04 PM, David E. Wheeler wrote:
see? Either uri_unescape() should be decoding that utf8() or you need
to do it *after* you call uri_unescape(). Hence the maybe it could be
considered a bug in
On Fri, Dec 17, 2010 at 18:04, David E. Wheeler da...@kineticode.com wrote:
On Dec 16, 2010, at 8:39 PM, Alex Hunsaker wrote:
Yeah. So I just wrote and tested this function on 9.0 with Perl 5.12.2:
CREATE OR REPLACE FUNCTION perlgets(
TEXT
) RETURNS TABLE(length INT, is_utf8
On Dec17, 2010, at 23:12 , Tomas Vondra wrote:
Well, not really - I haven't done any experiments with it. For two
columns selectivity equation is
(dist(A) * sel(A) + dist(B) * sel(B)) / (2 * dist(A,B))
where A and B are columns, dist(X) is number of distinct values in
column X and
On Fri, Dec 17, 2010 at 02:00, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
So, attached patch fixes the v18 regression wrt to script file encoding
and establish UTF-8 as the default encoding to consider to read a script
file. Thanks for your comments.
You probably compared wrong versions of
101 - 159 of 159 matches
Mail list logo
