On Fri, Dec 17, 2010 at 02:00, Dimitri Fontaine 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 source trees. The p
> 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
>> co
On Fri, Dec 17, 2010 at 18:04, David E. Wheeler 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 BOOL) LANGUAGE pl
On Fri, Dec 17, 2010 at 18:22, David E. Wheeler 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 uri_unescape(
On Fri, Dec 17, 2010 at 22:32, David Christensen wrote:
>
> 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 La
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
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(2
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 choic
On Sat, Dec 18, 2010 at 07:12, Peter Eisentraut 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 expanded auto.
H
On Fri, Dec 17, 2010 at 11:49, Shigeru HANADA 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 and file_fdw patches.
We
On Fri, Dec 17, 2010 at 9:47 PM, Andreas Karlsson 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 for the no
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 (pgsql-hacker
On Fri, Dec 17, 2010 at 9:30 PM, Andreas Karlsson wrote:
> On Fri, 2010-12-17 at 21:20 -0500, Robert Haas wrote:
>> On Fri, Dec 17, 2010 at 9:14 PM, Andreas Karlsson wrote:
>> > What it does is gets rid of the incorrect completion which comes from
>> > the completion rule for "SET foo TO bar" by
On Fri, 2010-12-17 at 21:20 -0500, Robert Haas wrote:
> On Fri, Dec 17, 2010 at 9:14 PM, Andreas Karlsson 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" higher up in
On Fri, Dec 17, 2010 at 9:14 PM, Andreas Karlsson 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" higher up
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
On Fri, Dec 17, 2010 at 7:35 PM, Josh Berkus 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 mean, it wo
On Fri, Dec 17, 2010 at 8:34 PM, andreas 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 this behaviour. :
On Fri, Dec 17, 2010 at 4:17 PM, Tom Lane 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 is writing t
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: Shou
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
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,
> 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 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 fo
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
On Fri, Dec 17, 2010 at 6:49 PM, Josh Berkus wrote:
> On 12/17/10 3:34 PM, Robert Haas wrote:
>> On Fri, Dec 17, 2010 at 6:09 PM, Josh Berkus wrote:
>>> Oh, *I* understand the difference. Any app developer is going to see it
>>> as stupidly arbitrary, though.
>>
>> Speaking as someone who spent
On 12/17/10 3:34 PM, Robert Haas wrote:
> On Fri, Dec 17, 2010 at 6:09 PM, Josh Berkus 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".
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 Fri, Dec 17, 2010 at 6:09 PM, Josh Berkus 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: http://www.enterpri
>> 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
> f
> > 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'::Integ
On Sat, Dec 18, 2010 at 00:05, Josh Berkus 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:
>>> int(1.234e+01)
12
Josh Berkus 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 not arbitrary
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 c1
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 v
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 a
Excerpts from Tom Lane's message of vie dic 17 18:21:48 -0300 2010:
> Alvaro Herrera 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
> > HandleF
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 c
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
bef
Tomas Vondra 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 of these t
Alvaro Herrera 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. Well, the ps_status upda
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
> Alvaro Herrera 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 tag.
>
> > Are
[ hit send too soon ... ]
Robert Haas 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 don't believe an extr
Robert Haas 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, tom lane
--
Sent via
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 s
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
ind
In response to Jeff Janes :
> On Fri, Dec 17, 2010 at 12:16 PM, Bill Moran wrote:
> > In response to Tom Lane :
> >
> >> Josh Berkus writes:
> >> > postgres=# select '1e+01'::Integer
> >> > postgres-# ;
> >> > ERROR: invalid input syntax for integer: "1e+01"
> >>
> >> I have never heard of any
On Fri, Dec 17, 2010 at 3:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane wrote:
>>> Yeah. I think that BM_UNLOGGED might be a poor choice for the flag name,
>>> just because it overstates what the bufmgr needs to assume.
>
>> I was actually thinking of
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 b
In response to "Joshua D. Drake" :
>
> > 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
On Fri, Dec 17, 2010 at 12:16 PM, Bill Moran wrote:
> In response to Tom Lane :
>
>> Josh Berkus 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
>
Christophe Pettus 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 reason
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-hacker
On Fri, Dec 17, 2010 at 3:31 PM, Joshua D. Drake 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 both
>
> 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 'prin
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-h
"Joshua D. Drake" 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 2010, 16:22:5
On Fri, 2010-12-17 at 14:35 -0500, Tom Lane wrote:
> Josh Berkus 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 writes:
> In response to Tom Lane :
>> 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
> SELECT 1.000::Integer;
> works. An
In response to Tom Lane :
> Josh Berkus 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 distinguishes integers fr
Robert Haas writes:
> On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane wrote:
>> Yeah. I think that BM_UNLOGGED might be a poor choice for the flag name,
>> just because it overstates what the bufmgr needs to assume.
> I was actually thinking of adding BM_UNLOGGED even before this
> discussion, becaus
Robert Haas writes:
> On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane wrote:
>> plpgsql's parser is rickety enough that I don't have a lot of confidence
>> in its ability to do things that way.
> Bummer. Rickety is not good.
Agreed, but it's not entirely the parser's fault: the language
definition i
On Fri, Dec 17, 2010 at 3:03 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 17.12.2010 21:32, Robert Haas wrote:
>>> I guess the question is whether it's right to conflate "table is
>>> unlogged" with "LSN is fake". It's not immediately obvious to me that
>>> those concepts are isomorphi
Heikki Linnakangas writes:
> On 17.12.2010 21:32, Robert Haas wrote:
>> I guess the question is whether it's right to conflate "table is
>> unlogged" with "LSN is fake". It's not immediately obvious to me that
>> those concepts are isomorphic, although though the reverse isn't
>> obvious to me ei
On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane wrote:
>>> Robert Haas writes:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distin
Robert Haas writes:
> On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Unfortunately, there are likely to be a limited number of such
>>> keywords available. While I agree it's helpful to have a clear
>>> distinction between what FOR does and what FOREACH does, it's w
On 17.12.2010 21:32, Robert Haas wrote:
I guess the question is whether it's right to conflate "table is
unlogged" with "LSN is fake". It's not immediately obvious to me that
those concepts are isomorphic, although though the reverse isn't
obvious to me either.
The buffer manager only needs to
On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> Unfortunately, there are likely to be a limited number of such
>> keywords available. While I agree it's helpful to have a clear
>> distinction between what FOR does and what FOREACH does, it's wholly
>> conventional here
Excerpts from Tom Lane's message of vie dic 17 16:25:17 -0300 2010:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
> >> Hm, what about pgstat_report_activity()?
>
> > I wasn't sure about that, because of the overhead, but now that I look
> > at it
Josh Berkus 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 distinguishes integers from other
numbers at all). I'm not excite
On Fri, Dec 17, 2010 at 2:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> Another possibly-useful thing about mandating a full page header for
>> every page is that it might give us a way of avoiding unnecessary full
>> page writes. As I wrote previously:
>
> Could we do that via a bufmgr status
On Fri, Dec 17, 2010 at 2:22 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 17.12.2010 21:07, Tom Lane wrote:
>>> IIUC, the problem is that the bufmgr might think that a GIST NSN is an
>>> LSN that should affect when to force out a dirty buffer? What if we
>>> taught it the difference?
Robert Haas writes:
> Another possibly-useful thing about mandating a full page header for
> every page is that it might give us a way of avoiding unnecessary full
> page writes. As I wrote previously:
Could we do that via a bufmgr status bit, instead? Heikki's idea has
the merit that it actual
On Fri, Dec 17, 2010 at 2:07 PM, Tom Lane wrote:
> Robert Haas writes:
> IIUC, the problem is that the bufmgr might think that a GIST NSN is an
> LSN that should affect when to force out a dirty buffer? What if we
> taught it the difference? We could for example dedicate a pd_flags
> bit to mar
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
>> Hm, what about pgstat_report_activity()?
> I wasn't sure about that, because of the overhead, but now that I look
> at it, it's supposed to be cheaper than changing the ps_status in some
> cases, so I
2010/12/17 Tom Lane :
> Pavel Stehule writes:
>> Second semi argument for using ARRAY keyword is a verbosity of
>> PL/pgSQL. So from this perspective a ARRAY should be minimally
>> optional and ensure, so expr result will be really a array. But with a
>> optional ARRAY keyword we leaving a simple
Heikki Linnakangas writes:
> On 17.12.2010 21:07, Tom Lane wrote:
>> IIUC, the problem is that the bufmgr might think that a GIST NSN is an
>> LSN that should affect when to force out a dirty buffer? What if we
>> taught it the difference? We could for example dedicate a pd_flags
>> bit to marki
Excerpts from Tom Lane's message of vie dic 17 12:41:06 -0300 2010:
> Alvaro Herrera 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 tag.
>
> > Are
On 17.12.2010 21:07, Tom Lane wrote:
IIUC, the problem is that the bufmgr might think that a GIST NSN is an
LSN that should affect when to force out a dirty buffer? What if we
taught it the difference? We could for example dedicate a pd_flags
bit to marking pages whose pd_lsn isn't actually an
Pavel Stehule writes:
> Second semi argument for using ARRAY keyword is a verbosity of
> PL/pgSQL. So from this perspective a ARRAY should be minimally
> optional and ensure, so expr result will be really a array. But with a
> optional ARRAY keyword we leaving a simple enhancing in future (on
> pa
Robert Haas writes:
> Unfortunately, there are likely to be a limited number of such
> keywords available. While I agree it's helpful to have a clear
> distinction between what FOR does and what FOREACH does, it's wholly
> conventional here and won't be obvious without careful reading of the
> do
2010/12/17 Robert Haas :
> On Fri, Dec 17, 2010 at 1:38 PM, Tom Lane wrote:
>> "David E. Wheeler" writes:
>>> On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
Well, we did beat up Pavel over trying to shoehorn this facility into
the existing FOR syntax, so I can hardly blame him for thinkin
On 17.12.2010 21:04, Robert Haas wrote:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distinction between what FOR does and what FOREACH does, it's wholly
conventional here and won't be obvious without careful readin
On Fri, Dec 17, 2010 at 11:51, Alex Hunsaker wrote:
> Also note this is just a simple test case, perl *could* elect to store
> completely ascii strings internally as utf8. In those cases we still
Erm... not ascii I mean bytes >127
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Robert Haas writes:
> Given the foregoing discussion, I see only two possible paths forward here.
> 1. Just decide that that unlogged tables can't have GIST indexes, at
> least until someone figures out a way to make it work. That's sort of
> an annoying limitation, but I think we could live wit
> We would need an extra keyword if there were some third kind of
> iteration that was fundamentally different from either of these, but
> like I said, I don't see a plausible candidate. So right at the moment,
> I'm leaning to the position that we could do without the ARRAY keyword
> in FOREACH.
Folks,
Is there any good reason that this works:
postgres=# select ('1e+01'::numeric)::integer
postgres-# ;
int4
--
10
But this doesn't?
postgres=# select '1e+01'::Integer
postgres-# ;
ERROR: invalid input syntax for integer: "1e+01"
LINE 1: select '1e+01'::Integer
... or did we just
On Fri, Dec 17, 2010 at 1:38 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
>>> Well, we did beat up Pavel over trying to shoehorn this facility into
>>> the existing FOR syntax, so I can hardly blame him for thinking this
>>> way. The question i
Given the foregoing discussion, I see only two possible paths forward here.
1. Just decide that that unlogged tables can't have GIST indexes, at
least until someone figures out a way to make it work. That's sort of
an annoying limitation, but I think we could live with it.
+1
In the small s
On Fri, Dec 17, 2010 at 12:58 PM, Tomas Vondra wrote:
> In the end, all they need to compute an estimate is number of distinct
> values for each of the columns (we already have that in pg_stats) and a
> number of distinct values for the group of columns in a query. They
> really don't need any mul
On Tue, Dec 14, 2010 at 5:14 PM, Robert Haas wrote:
> On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
>>> wrote:
Hmm, the first idea that comes to mind is to use a counter like the
GetXLogRecPtrForTemp() c
On Fri, Dec 17, 2010 at 08:30, David Fetter wrote:
> On Thu, Dec 16, 2010 at 07:24:46PM -0800, David Wheeler wrote:
>> On Dec 16, 2010, at 6:39 PM, Alex Hunsaker wrote:
>>
>> > Grr that should error out with "Invalid server encoding", or worst
>> > case should return a length of 3 (it utf8 encoded
"David E. Wheeler" writes:
> On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
>> Well, we did beat up Pavel over trying to shoehorn this facility into
>> the existing FOR syntax, so I can hardly blame him for thinking this
>> way. The question is whether we're willing to assume that FOREACH will
>> b
On Wed, Dec 15, 2010 at 2:20 AM, Heikki Linnakangas
wrote:
> Looks ok. I'd suggest rewording this comment though:
>
> [ the comment in question ]
>
> It's a bit hard to follow, as it first lists exceptions on when we must
> flush XLOG immediately, and then lists conditions on when we can skip it.
On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
> Well, we did beat up Pavel over trying to shoehorn this facility into
> the existing FOR syntax, so I can hardly blame him for thinking this
> way. The question is whether we're willing to assume that FOREACH will
> be limited to iterating over array
Dne 12.12.2010 15:43, Heikki Linnakangas napsal(a):
> On 12.12.2010 15:17, Martijn van Oosterhout wrote:
>> On Sun, Dec 12, 2010 at 03:58:49AM +0100, Tomas Vondra wrote:
>> Very cool that you're working on this.
>
> +1
>
>>> Lets talk about one special case - I'll explain how the proposed
>>> sol
2010/12/17 Andrew Dunstan :
>
>
> On 12/17/2010 12:15 PM, Pavel Stehule wrote:
>>
>> 2010/12/17 Itagaki Takahiro:
>>>
>>> It should be not a main subject, but I remember there was a discussion
>>> that "IN ARRAY array-expression" looks redundant for a literal array:
>>>
>>> IN ARRAY ARRAY[1, 3, 5]
Andrew Dunstan writes:
> On 12/17/2010 12:15 PM, Pavel Stehule wrote:
>> The reason for this is bigger space for possible
>> future features related to FOREACH loop.
> So what you're saying is we need to allow ugliness now so we can have
> more ugliness in future? I don't find that a convincing
Merlin Moncure writes:
> On Fri, Dec 17, 2010 at 12:15 PM, Tom Lane wrote:
>> [ scratches head... ] I don't follow what you envision this doing,
>> exactly?
> It's like _pg_expandarray but alterted support multiple dimensions:
> select * from unnest_dims(array[['a','b'],['c','d']]) returns
> [
On 12/17/2010 12:15 PM, Pavel Stehule wrote:
2010/12/17 Itagaki Takahiro:
It should be not a main subject, but I remember there was a discussion
that "IN ARRAY array-expression" looks redundant for a literal array:
IN ARRAY ARRAY[1, 3, 5]
Are there any improvement for the issue?
yes. It
1 - 100 of 160 matches
Mail list logo
