Tom Lane írta:
> I wrote:
>
>> The fundamental reason that there's a problem here is that ecpg has
>> decided to accept a syntax that the backend doesn't (ie, FETCH with a
>> fetch direction but no FROM/IN). I think that that's basically a bad
>> idea: it's not helpful to users to be inconsiste
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> I'd look at requiring from_in as being the least-bad alternative.
>>>
>
>
>> Hm. "FETCH FORWARD variable" can only be a rowcount var
>> only if there's something afterwards, no? With the proposed
>> change in
marcin mank wrote:
> You are correct, I think, though this does not solve the division problem:
>
As a first goal I'm just attempting to reduce the EPSILON from 1.0E-6
down to 1.0E-015 (give or take). The current regression test suite works
fine down to 1.0E-09. At 1.0E-10 errors appear, not in
On Fri, Aug 07, 2009 at 06:28:34PM -0400, Tom Lane wrote:
> David Fetter writes:
> > I am not suggesting that this change be immediate, and it's not ivory
> > tower. It's just how everybody else does it.
>
> You keep saying that, and it's completely meaningless. What do you know
> about the dev
Jeff Davis escribió:
> On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote:
> > b) it allows constructors for data types (ANSI SQL)
> >
> > datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type
>
> Can you describe this case in more detail? What section of SQL are you
> referrin
On Sun, Jul 19, 2009 at 10:56 PM, Tom Lane wrote:
> I think we want something along the lines of relation_is_distinct_for
> with a list of columns and a list of comparison operators, where the
> first-cut implementation will be to look for matching indexes.
> This will be different from query_is_di
On Sat, Aug 8, 2009 at 3:07 AM, Paul Matthews wrote:
> IEEE754 does not allow two number X and Y, such that X!=Y and (X-Y)==0.
> And since IEEE754 has been around since the 70's or 80's I think we can
> start relying on its existence and behavior by now.
>
You are correct, I think, though this do
On Sun, 2009-07-26 at 15:29 +0200, Pavel Stehule wrote:
> Hello
>
> new patch add new contrib "transformations" with three modules
> anotation, decode and json.
>
> These modules are ported from my older work.
>
> Before applying this patch, please use named-fixed patch too. The hook
> doesn't n
On Sat, Aug 8, 2009 at 1:12 PM, Bruce Momjian wrote:
> You are right you don't have to justify anything, but neither can you
> claim ownership of the patch/feature and complain that others are
> working on it too. This is a community project --- if you want your
> patches to remain your property,
On Sat, Aug 8, 2009 at 9:11 PM, Jeff Davis wrote:
> On Thu, 2009-07-30 at 00:01 -0400, Robert Haas wrote:
>> The JSON transformation provides functionality which is very similar
>> to what we also offer for XML. I sort of think we ought to just
>> provide that, rather than making it an add-on. I
On Sat, Aug 8, 2009 at 12:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> As we are now into the last week of this CommitFest (hopefully), I
>> have moved all of the patches that were listed as "Waiting on Author"
>> to "Returned with Feedback". I feel pretty good about doing this
>> because most
On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote:
> b) it allows constructors for data types (ANSI SQL)
>
> datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type
Can you describe this case in more detail? What section of SQL are you
referring to?
Regards,
Jeff Davis
On Thu, 2009-07-30 at 00:01 -0400, Robert Haas wrote:
> The JSON transformation provides functionality which is very similar
> to what we also offer for XML. I sort of think we ought to just
> provide that, rather than making it an add-on. I have found it to be
> a tremendously attractive alterna
Robert Haas wrote:
> Yeah. I usually build the docs and read them if I'm making er
> proposing... an extensive change, but for simple stuff I just edit the
> SGML and figure that if it looks sane it probably is.
>
> I certainly don't test the doc portions of patches I review unless I
> see so
While following up a comment from Tom on my blog, I discovered that some
9 1/2 years ago in a patch bearing the comment:
Fixed psql double quoting of SQL ids
Fixed libpq printing functions
the documentation of psql's --no-readline option was removed
(psql-ref.sgml v 1.23). I think
Tom Lane wrote:
> Perhaps an appropriate thing to do is separate out the representation
> change from the other new features, and apply just the latter for now.
> Or maybe we should think about having two versions of hstore. This
> is all tied up in the problem of having a decent module infrastruc
Mark Kirkwood wrote:
Mark Kirkwood wrote:
Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:38 AM, Mark
Kirkwood wrote:
With respect to the sum of wait times being not very granular, yes
- quite
true. I was thinking it is useful to be able to answer the question
'where
is my wait time being s
I wrote:
> The fundamental reason that there's a problem here is that ecpg has
> decided to accept a syntax that the backend doesn't (ie, FETCH with a
> fetch direction but no FROM/IN). I think that that's basically a bad
> idea: it's not helpful to users to be inconsistent, and it requires ugly
>
Boszormenyi Zoltan writes:
> Tom Lane írta:
>> I'd look at requiring from_in as being the least-bad alternative.
> Hm. "FETCH FORWARD variable" can only be a rowcount var
> only if there's something afterwards, no? With the proposed
> change in fetch_direction (moving FORWARD and BACKWARD
> witho
> Well, since I've written the patch I am for it :) Probably with that
> GRANT ON * and GRANT ON schema.* as it has indeed very low probability
> that something like that will be in standard with different meaning and
> also it's mysql compatible (which is the only db currently having this
> featu
Josh Berkus writes:
> Given that the FSM is now auto-managing, is there any reason to have
> this tool at all?
Maybe not, but I'd be inclined to wait a release or so until we have
more field experience with the new FSM. If, in a year, FSM is something
nobody worries about anymore, we can kill th
On 8/8/09 10:50 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Is there any reason we didn't move the pg_freespace function from
>>> contrib to core?
>> Is there a reason we *should* move it? The current definition doesn't
>> leave me feeling that it's more than a low-l
Heikki Linnakangas writes:
> Tom Lane wrote:
>> What if PREPARE simply didn't write the 2PC file at all, except into WAL?
> Interesting idea, might be worth performance testing. Peeking into the
> WAL files during normal operation feels naughty, but it should work.
> However, if the bottleneck is
Tom Lane wrote:
> What if PREPARE simply didn't write the 2PC file at all, except into WAL?
> Then, make CheckPointTwoPhase write the 2PC file for any still-live
> GXACT, by means of reaching into the WAL and pulling the data out.
> All it would need for that is the LSN of the WAL record, which I t
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Michael Meskes Ărta:
>>
>>> The problem is that SignedIconst might be a char variable,
>>> too. So how shall the parser know whether str in "FETCH BACKWARD :str"
>>> carries
>>> the number of records to move backwards ot the cursor name.
>
Boszormenyi Zoltan writes:
> Michael Meskes Ãrta:
>> The problem is that SignedIconst might be a char variable,
>> too. So how shall the parser know whether str in "FETCH BACKWARD :str"
>> carries
>> the number of records to move backwards ot the cursor name.
> This was the problem, yes.
>> A
Michael Meskes írta:
> On Sat, Aug 08, 2009 at 07:21:59PM +0200, Boszormenyi Zoltan wrote:
>
>>> A possible solution
>>> would be to force a numeric variable for numeric data.
>>>
>> By which you would remove a feature.
>> With the proposed core grammar change,
>> the feature where you c
Tom Lane wrote:
> Alvaro Herrera writes:
> > Is there any reason we didn't move the pg_freespace function from
> > contrib to core?
>
> Is there a reason we *should* move it? The current definition doesn't
> leave me feeling that it's more than a low-level hacker's tool.
No specific reason. I
On Sat, Aug 08, 2009 at 07:21:59PM +0200, Boszormenyi Zoltan wrote:
> > A possible solution
> > would be to force a numeric variable for numeric data.
>
> By which you would remove a feature.
> With the proposed core grammar change,
> the feature where you can pass the number of
> records to be f
Michael Meskes írta:
> On Sat, Aug 08, 2009 at 05:48:57PM +0200, Boszormenyi Zoltan wrote:
>
>> ...
>> "/usr/bin/perl" ./parse.pl . < ../../../../src/backend/parser/gram.y >
>> preproc.y
>> /usr/bin/bison -d -o preproc.c preproc.y
>> preproc.y: conflicts: 2 shift/reduce
>> preproc.y: expected 0
Simon Riggs wrote:
>
> On Sat, 2009-08-08 at 00:02 -0400, Bruce Momjian wrote:
>
> > > Also, to my knowledge, nobody has really looked through the results to
> > > see if they are any good, so the success of the endeavor remains in
> > > doubt from my point of view. That's a bit of a shame becau
On Sat, Aug 08, 2009 at 05:48:57PM +0200, Boszormenyi Zoltan wrote:
> ...
> "/usr/bin/perl" ./parse.pl . < ../../../../src/backend/parser/gram.y >
> preproc.y
> /usr/bin/bison -d -o preproc.c preproc.y
> preproc.y: conflicts: 2 shift/reduce
> preproc.y: expected 0 shift/reduce conflicts
> make[4]:
Robert Haas writes:
> As we are now into the last week of this CommitFest (hopefully), I
> have moved all of the patches that were listed as "Waiting on Author"
> to "Returned with Feedback". I feel pretty good about doing this
> because most of these patches have been waiting on author for a lon
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Is there a good reason for $subject, other than that the code is
> > > entangled
> > > with other ALTER TABLE code?
> >
> > I think it could be lower, but it would take nontrivial rest
On Sat, 2009-08-08 at 00:02 -0400, Bruce Momjian wrote:
> > Also, to my knowledge, nobody has really looked through the results to
> > see if they are any good, so the success of the endeavor remains in
> > doubt from my point of view. That's a bit of a shame because I am
> > interested in putti
Brendan Jurd writes:
> 2009/8/3 Tom Lane :
>> Uh, no, we had better support more. The actual limit of the current
>> numeric format is 1e+131072.
> Given your comment above I'm thinking it reasonable to use an int32 to
> store the exponent -- will that be safe?
Seems reasonable to me.
> That w
Tom Lane írta:
> Michael Meskes writes:
>
>> Tom, AFAICT we only need one core grammar change, moving the cursor name to
>> it's own rule that only resolves back to name. This rule should be eliminated
>> by bison during the build process anyway, so I see no problem adding it. It
>> does make t
Michael Meskes írta:
> On Mon, Aug 03, 2009 at 06:59:30PM +0200, Boszormenyi Zoltan wrote:
>
>>> Why is this messing with the core grammar?
>>>
>> ...
>>
>
> Zoltan, could you please explain why you unrolled FORWARD and BACKWARD? I
> tried
> applying the rest of your patch, without
Michael Meskes writes:
> Tom, AFAICT we only need one core grammar change, moving the cursor name to
> it's own rule that only resolves back to name. This rule should be eliminated
> by bison during the build process anyway, so I see no problem adding it. It
> does make the ecpg changes way smalle
Robert Haas writes:
> On Sat, Aug 8, 2009 at 9:31 AM, Heikki
> Linnakangas wrote:
>> I'm a bit disappointed by the performance gains. I would've expected
>> more, given a decent battery-backed-up cache to buffer the WAL fsyncs.
> It doesn't seem that surprising to me that a write to shared memory
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Quite aside from that, the fixed size of shared memory makes this seem
>> pretty impractical.
> Most state files are small. If one doesn't fit in the area reserved for
> this, it's written to disk as usual. It's just an optimization.
What evidence
Robert Haas wrote:
> On Aug 7, 2009, at 11:50 PM, Bruce Momjian wrote:
>
> > David Fetter wrote:
> >>> Odds are that the patch submitters will not understand enough to
> >>> know how to modify pg_migrator, but just knowing something broke is
> >>> usually enough for the hackers group to find a fi
On Mon, Aug 03, 2009 at 06:59:30PM +0200, Boszormenyi Zoltan wrote:
> > Why is this messing with the core grammar?
> ...
Zoltan, could you please explain why you unrolled FORWARD and BACKWARD? I tried
applying the rest of your patch, without this unrolling but didn't get any
shift/reduce problem.
On Sat, Aug 8, 2009 at 9:31 AM, Heikki
Linnakangas wrote:
> Tom Lane wrote:
>> Michael Paquier writes:
>>> Based on an idea of Heikki Linnakangas, here is a patch in order to improve
>>> 2PC
>>> by sending the state files of prepared transactions to shared memory instead
>>> of disk.
>>
>> I don't
On Sun, Jul 19, 2009 at 3:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> Tom, do you think the "independent subproblem" stuff from last night
>> would be worth pursuing?
>
> It's worth looking into. I'm not certain if it will end up being a good
> idea or not. Right now the joinlist collapse co
Tom Lane wrote:
> Michael Paquier writes:
>> Based on an idea of Heikki Linnakangas, here is a patch in order to improve
>> 2PC
>> by sending the state files of prepared transactions to shared memory instead
>> of disk.
>
> I don't understand how this can possibly work. The entire point of
> 2PC
On Sat, Aug 8, 2009 at 12:02 AM, Bruce Momjian wrote:
> Well, Simon stated that your version should now be used as the most
> recent one, so I would call that a success.
Fair enough, but it still needs more work. I had some review comments
I was hoping to get responses to, in the section beginnin
Michael Meskes írta:
> On Fri, Aug 07, 2009 at 12:08:00PM -0400, Alvaro Herrera wrote:
>
>> I think we're normally OK with mentioning the authors, i.e. "Author:
>>
>
> Yes, it's OK, but I think we normally only acknowledge the author in our
> commit
> messages, don't we?
>
>
>> such and
A Dissabte, 8 d'agost de 2009, Pierre Frédéric Caillaud va escriure:
> I guess it would need some experimenting with the values, and a
> per-tablespace setting, but since lots of people use Linux Software RAID1
> on servers, this might be interesting...
>
> You guys want to try it ?
Your tests inv
This is a spinoff of the current work on compression...
I've discovered that linux doesn't apply readahead to sparse files.
So I added a little readahead in seq scans.
Then I realized this might also be beneficial for the standard Postgres.
On my RAID1 it shows some pretty drastic effects.
The
On Fri, Aug 07, 2009 at 12:08:00PM -0400, Alvaro Herrera wrote:
> I think we're normally OK with mentioning the authors, i.e. "Author:
Yes, it's OK, but I think we normally only acknowledge the author in our commit
messages, don't we?
> such and such", but the (C) line should attribute copyright
On Fri, Aug 07, 2009 at 04:03:38PM +0200, Boszormenyi Zoltan wrote:
> I added notice about the PostgreSQL license. Is it ok?
> Or should I resend without indicating the authors?
Normally all our source files are "Copyright PostgreSQL Global Development
Group" and I don't see a reason why this shou
2009/8/3 Tom Lane :
> Uh, no, we had better support more. The actual limit of the current
> numeric format is 1e+131072.
>
Given your comment above I'm thinking it reasonable to use an int32 to
store the exponent -- will that be safe?
That would allow for a maximum of 10 exponent digits. As an
53 matches
Mail list logo
