Hello
I though, so simple SQL functions should be inlined everywhere. When I
tested sample for recent discussion, I found so immutable flag breaks
inlining.
Is it bug?
postgres=# create or replace function foo(a int) returns int as $$
select $1+1$$ language sql STRICT IMMUTABLE;
CREATE FUNCTION
On Sat, Aug 1, 2009 at 7:27 AM, Dimitri Fontaine wrote:
> Unless you want me to test for impact on planner choices (even if we already
> know it has impact on pg_statistic), I'd say it's ready for commiter.
Great, thanks for the review. I think if stadistinct is getting
populated that's sufficien
On Fri, Jul 31, 2009 at 8:46 AM, Pavel Stehule wrote:
> 2009/7/31 Bernd Helmle :
>> --On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle
>> wrote:
>>
Hi,
I sending a little bit modified version - I removed my forgotten
comment in gram.y
>>>
>>> Thanks, i'll look on it asap.
>
On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehule wrote:
> 2009/7/30 Tom Lane :
>> Pavel Stehule writes:
>>> 2009/7/30 Robert Haas :
On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
> Hmm. For what it's worth, I think Pavel makes a good point about the
> number of exponent digits --
2009/8/2 Robert Haas :
> On Fri, Jul 31, 2009 at 8:46 AM, Pavel Stehule wrote:
>> 2009/7/31 Bernd Helmle :
>>> --On Montag, Juli 27, 2009 15:24:12 +0200 Bernd Helmle
>>> wrote:
>>>
> Hi,
>
> I sending a little bit modified version - I removed my forgotten
> comment in gram.y
>
2009/8/2 Robert Haas :
> On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehule wrote:
>> 2009/7/30 Tom Lane :
>>> Pavel Stehule writes:
2009/7/30 Robert Haas :
> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd wrote:
>> Hmm. For what it's worth, I think Pavel makes a good point about the
Hi Robert, Hi all,
On Thursday 30 July 2009 05:05:48 Robert Haas wrote:
> OK, here's the updated version of my machine-readable explain output
> patch. This needed heavy updating as a result of the changes that Tom
> asked me to make to the explain options patch, and the further changes
> he made
Pavel Stehule writes:
> I though, so simple SQL functions should be inlined everywhere. When I
> tested sample for recent discussion, I found so immutable flag breaks
> inlining.
Your example proves nothing of the sort, since you have forgotten to
allow for immutable functions being folded to con
Pavel Stehule writes:
> Tom, please, can you write your opinion on my last proposal - print
> ### with raise warning.
The idea of printing a warning seems completely horrid to me. From a
logical point of view, either we think it's an error or we don't. From
a practical point of view, warnings u
There wasn't any response to this comment:
marcin mank writes:
> ALTER COLUMN SET DISTINCT
> feels like adding a unique constraint.
> ALTER COLUMN SET STATISTICS DISTINCT ?
> ALTER COLUMN SET STATISTICS NDISTINCT ?
I don't want to add a new keyword, but "SET STATISTICS DISTINCT" would
be an eas
2009/8/2 Tom Lane :
> There wasn't any response to this comment:
>
> marcin mank writes:
>> ALTER COLUMN SET DISTINCT
>> feels like adding a unique constraint.
>
>> ALTER COLUMN SET STATISTICS DISTINCT ?
>> ALTER COLUMN SET STATISTICS NDISTINCT ?
>
> I don't want to add a new keyword, but "SET STA
Hi,
The patch looks good.
Comments:
1. The docs should be clarified a little. For instance, it should have a
link back to the definition of a prefix search (12.3.2). I included my
doc suggestions as an attachment.
2. dsynonym_init() uses findwrd() in a slightly confusing (and perhaps
fragile) w
A little while ago, I saw a compiler warning creep in:
In file included from gram.y:11202:
scan.c: In function ‘yy_try_NUL_trans’:
scan.c:15765: warning: unused variable ‘yyg’
I know there were some changes to minimum versions, but I think I have
those versions (listed below). I don't know if oth
Jeff Davis writes:
> A little while ago, I saw a compiler warning creep in:
> In file included from gram.y:11202:
> scan.c: In function âyy_try_NUL_transâ:
> scan.c:15765: warning: unused variable âyygâ
Yeah, this is a bogosity in the current release of "flex".
http://sourceforge.net/trac
Tom Lane escreveu:
> The real bottom line for to_char issues is almost always that we should
> do what Oracle does. Has anyone checked this behavior on Oracle?
>
That was my point too. See [1].
[1] http://archives.postgresql.org/pgsql-hackers/2009-07/msg01870.php
--
Euler Taveira de Oliveir
2009/8/2 Euler Taveira de Oliveira :
> Tom Lane escreveu:
>> The real bottom line for to_char issues is almost always that we should
>> do what Oracle does. Has anyone checked this behavior on Oracle?
>>
> That was my point too. See [1].
>
> [1] http://archives.postgresql.org/pgsql-hackers/2009-07
On Sun, Aug 02, 2009 at 01:23:27PM -0400, Tom Lane wrote:
> There wasn't any response to this comment:
>
> marcin mank writes:
> > ALTER COLUMN SET DISTINCT
> > feels like adding a unique constraint.
>
> > ALTER COLUMN SET STATISTICS DISTINCT ?
> > ALTER COLUMN SET STATISTICS NDISTINCT ?
>
> I
On Wed, Jul 22, 2009 at 2:17 PM, Andrew
Gierth wrote:
> Unless I hear any objections I will proceed accordingly...
At this point it's been 12 days since this was written and no updated
patch has been posted, so I think it's well past time to move this to
"Returned with Feedback". Accordingly I'm
On Sun, Aug 2, 2009 at 12:06 PM, Andres Freund wrote:
> Hi Robert, Hi all,
>
> On Thursday 30 July 2009 05:05:48 Robert Haas wrote:
>> OK, here's the updated version of my machine-readable explain output
>> patch. This needed heavy updating as a result of the changes that Tom
>> asked me to make t
On Wed, Jul 29, 2009 at 9:28 AM, Robert Haas wrote:
> On Wed, Jul 29, 2009 at 8:43 AM, Peter Eisentraut wrote:
>> On Sunday 28 June 2009 21:21:35 Robert Haas wrote:
>>> I think that our dependencies for generated header files (gram.h,
>>> fmgroids.h, probes.h) are not as good as they could be. Wha
Robert Haas escribió:
> Is it conceivable that there might be a dependency on one of the
> generated header files from someplace in src other than src/backend?
> If so, it seems like that might be an argument for leaving it as I had
> it.
Well, plperl.c includes fmgroids.h.
--
Alvaro Herrera
Dimitri Fontaine writes:
> Yes, and as I didn't have the time to install filterdiff I've attached
> a revision of your patch in git format which adresses the problem I
> mentioned, in a tarball also containing raw notes, tests, and
> regression.{out,diffs}.
Applied with assorted corrections
2009/8/3 Pavel Stehule :
> 2009/8/2 Euler Taveira de Oliveira :
>> Tom Lane escreveu:
>>> The real bottom line for to_char issues is almost always that we should
>>> do what Oracle does. Has anyone checked this behavior on Oracle?
>>>
>> That was my point too. See [1].
>>
>> [1] http://archives.po
Robert Haas writes:
> On Sun, Aug 2, 2009 at 12:06 PM, Andres Freund wrote:
>> - Currently a value scan looks like »Values Scan on "*VALUES*"« What about
>> adding its alias at least in verbose mode? This currently is inconsistent
>> with
>> other scans.
> I don't know why this doesn't work, but
On Sunday 02 August 2009 23:34:04 Robert Haas wrote:
> On Sun, Aug 2, 2009 at 12:06 PM, Andres Freund wrote:
> > Hi Robert, Hi all,
> >
> > On Thursday 30 July 2009 05:05:48 Robert Haas wrote:
> >> OK, here's the updated version of my machine-readable explain output
> >> patch. This needed heavy u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'm testing pg_migrator, and running into an annoyance with timestamps
while trying to verify the conversion. My steps were:
install pg_migrator under 8.4 cluster
run pg_migrator in copy mode -- pg_migrator reports success
start up 8.4 cluster
resto
Robert Haas writes:
>>> The reason for this regression is that Tom asked me to change
>>> ExplainStmt to just carry a list of nodes and to do all the parsing in
>>> ExplainQuery. Unfortunately, the TupleDesc is constructed by
>>> ExplainResultDesc() which can't trivially be changed to take an
>>>
Joe Conway writes:
> 1. Two functions were left in the 8.4 database
> pg_toasttbl_drop(oid)
> pg_toasttbl_recreate(oid, oid)
This is pg_migrator's fault --- it should probably clean those up
when it's done.
> 3. All timestamps in the data that have two decimal places on seconds,
>
On Sun, Aug 2, 2009 at 6:17 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Yes, and as I didn't have the time to install filterdiff I've attached
>> a revision of your patch in git format which adresses the problem I
>> mentioned, in a tarball also containing raw notes, tests, and
>> regression
Robert Haas writes:
> Thanks. The changes all look good - except I'm curious why %g vs. %f?
So as not to add ".00" unnecessarily. Positive values for ndistinct
should be treated as integers. (I considered adding an error check to
reject values like 20.5, but refrained...)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
> Joe Conway writes:
>> 1. Two functions were left in the 8.4 database
>> pg_toasttbl_drop(oid)
>> pg_toasttbl_recreate(oid, oid)
>
> This is pg_migrator's fault --- it should probably clean those up
> when it's done.
I f
On Monday 03 August 2009 01:57:48 Tom Lane wrote:
> Robert Haas writes:
> > > - The regression tests are gone?
> > Tom added some that look adequate to me to create_index.sql, as a
> > separate commit, so I don't think I need to do this in my patch any
> > more. Maybe some of those examples shoul
On Sun, Aug 2, 2009 at 7:57 PM, Tom Lane wrote:
> Well, of course the existing tests are not going to exercise XML or
> JSON output format. Dunno how much we care. I had supposed that
> XML or JSON would always emit all the fields and leave it to the
> recipient to suppress what they don't want.
On Sun, Aug 2, 2009 at 8:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> Thanks. The changes all look good - except I'm curious why %g vs. %f?
>
> So as not to add ".00" unnecessarily. Positive values for ndistinct
> should be treated as integers. (I considered adding an error check to
> re
We now have less than two weeks remaining in this CommitFest (assuming
we stick with the usual time table of one month), and I would say
we're in fairly good shape. There are less than a dozen patches left
that are waiting on people other than the committers, or that are
still under discussion. H
Brendan Jurd escreveu:
> Well, the examples Euler posted in the linked message above were using
> E+308. If I'm reading the Oracle docs correctly, that would have
> triggered Oracle's data type overflow error before even getting to
> to_char(); Oracle's NUMBER type only supports up to E+126. So w
Robert Haas writes:
> Unspecified Committer (3)
> =
> GRANT ON ALL IN schema
> DefaultACLs
> multi-threaded pgbench
Personally I was thinking of multi-threaded pgbench as being
Tatsuo-san's to commit, since that's his code originally.
regards, tom lane
Euler Taveira de Oliveira writes:
> As I said in a prior e-mail, Oracle has a diferent overflow limit (-84 to
> 127).
> In PostgreSQL, the numeric datatype can have up to 1000 digits (ie 1e+999) and
> the double precision datatype can have up to 309 digits (ie 1e-307 or 1e+308).
> We should suppo
2009/8/3 Euler Taveira de Oliveira :
> Brendan Jurd escreveu:
>> Euler, could you post results for a number which fits within Oracle's
>> data type but has three exponent digits (like 1E+100)?
>>
> I don't access to an Oracle Server now but it works fine up to the 127 limit.
> And differently to wh
On Sun, Aug 2, 2009 at 9:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> Unspecified Committer (3)
>> =
>> GRANT ON ALL IN schema
>> DefaultACLs
>> multi-threaded pgbench
>
> Personally I was thinking of multi-threaded pgbench as being
> Tatsuo-san's to commit, since that's his
Hi,
On Sat, Aug 1, 2009 at 5:27 AM, Tom Lane wrote:
> Fujii Masao writes:
>> I revised the patch according to the suggestion.
>
> Applied with some mostly-cosmetic editorial work.
Thank you very much!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
41 matches
Mail list logo
