Hi,
the test harness used for Postgres-R has been unbundled and is now
available separately in a first release version 0.1. With its async,
event driven nature it is specifically targetting distributed systems
and designed to allow easy reuse and rearrangment of test components.
Special thanks to
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate area (maybe we can add rownumbers)
see screenshot 2 (it is only mockup, real implementation can be more
inteligent in rows numbering)
I
2010/3/21 Craig Ringer :
> On 21/03/2010 8:03 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> Current form of function detail isn't too practical (see screenshot 1)
>>
>> we can move source code to separate area (maybe we can add rownumbers)
>>
>> see screenshot 2 (it is only mockup, real implementation
On 21/03/2010 10:33 PM, Pavel Stehule wrote:
2010/3/21 Craig Ringer:
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate area (maybe we can add rownumbers)
see screenshot 2 (it is only m
2010/3/21 Craig Ringer :
> On 21/03/2010 10:33 PM, Pavel Stehule wrote:
>>
>> 2010/3/21 Craig Ringer:
>>>
>>> On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate ar
Andrew Dunstan writes:
>> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
> I have just been looking at the xmlconcat bug on that list. I can't
> think of any better solution than parsing the resulting string to make
> sure it is well-formed before we return,
That might be a reasonab
Pavel Stehule writes:
> I understanding. But this functionality is implemented yet. My
> motivation is to design some tool for more easy searching n. row in
> source code (for interpretation error messages) and possibility to see
> this row in some context.
Why is this a good way to attack that?
2010/3/21 Tom Lane :
> Pavel Stehule writes:
>> I understanding. But this functionality is implemented yet. My
>> motivation is to design some tool for more easy searching n. row in
>> source code (for interpretation error messages) and possibility to see
>> this row in some context.
>
> Why is th
Tom Lane wrote:
Andrew Dunstan writes:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
I have just been looking at the xmlconcat bug on that list. I can't
think of any better solution than parsing the resulting string to make
sure it is well-formed before we return,
Tom Lane writes:
> Why is this a good way to attack that? If you think the context already
> provided in error messages isn't good enough, seems like the thing to do
> is fix the error messages. Nobody is going to want to dump out a
> multi-hundred-line function like this in order to identify wh
Craig Ringer wrote:
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate area (maybe we can add rownumbers)
see screenshot 2 (it is only mockup, real implementation can be more
inteligent
Dimitri Fontaine writes:
> I'm not sure what better tool than what Pavel is proposing we already
> have, though.
We have quite decent features for localizing syntax errors in functions, eg
regression=# create function foo(x int) returns int language plpgsql as $$
begin
return 1/;
end$$;
ERROR:
Tom Lane writes:
> ERROR: syntax error at end of input
> LINE 3: return 1/;
>^
> What I think is called for is extending that approach to run-time
> errors. plpgsql doesn't make any particular effort to provide that
> right now, but it easily could IMO. Pavel's proposal is
2010/3/21 Tom Lane :
> Dimitri Fontaine writes:
>> I'm not sure what better tool than what Pavel is proposing we already
>> have, though.
>
> We have quite decent features for localizing syntax errors in functions, eg
>
> regression=# create function foo(x int) returns int language plpgsql as $$
>
Hi,
I was looking at the VarBit data structure and found out that instead of
storing the number of bits in four bytes, we can save the number of bits
that are valid in the last byte. Since we already store the number of bytes
in Varlena Header, we can calculate the number of valid bits by doing
Gokulakannan Somasundaram writes:
>I was looking at the VarBit data structure and found out that instead of
> storing the number of bits in four bytes, we can save the number of bits
> that are valid in the last byte. Since we already store the number of bytes
> in Varlena Header, we can calcu
On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> I understanding. But this functionality is implemented yet. My
>> motivation is to design some tool for more easy searching n. row in
>> source code (for interpretation error messages) and possibility to see
>> this row
On Fri, Mar 19, 2010 at 2:09 PM, Gurjeet Singh wrote:
> Is there a way to avoid this double evaluation?
Maybe with a CTE?
WITH x AS (...) SELECT ...
It does look like surprising behavior.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Robert Haas writes:
> I'm not sure that Pavel's idea is the right way to attack the problem,
> but I don't agree with this either. Line numbers are really the only
> feasible way of identifying a position in a large function. I usually
> bring up the function source code in vi and then use j wit
> This might be worth considering in a release cycle where we were going
> to break on-disk data compatibility for some other reason. But I can
> hardly imagine wanting to do it by itself. Marginal space savings for
> the "bit" types just isn't that exciting.
>
> Maybe we should start a special s
bruce wrote:
> Josh Berkus wrote:
> > On 3/19/10 9:02 PM, Bruce Momjian wrote:
> > > I have completed the 9.0 release notes:
> > >
> > > http://developer.postgresql.org/pgdocs/postgres/release-9-0.html
> > >
> > > I kept the 9.0-alpha release notes in the SGML because people might want
> > > to
On Sun, Mar 21, 2010 at 4:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not sure that Pavel's idea is the right way to attack the problem,
>> but I don't agree with this either. Line numbers are really the only
>> feasible way of identifying a position in a large function. I usually
>> br
On Sun, Mar 21, 2010 at 6:14 PM, Bruce Momjian wrote:
> bruce wrote:
>> Josh Berkus wrote:
>> > On 3/19/10 9:02 PM, Bruce Momjian wrote:
>> > > I have completed the 9.0 release notes:
>> > >
>> > > http://developer.postgresql.org/pgdocs/postgres/release-9-0.html
>> > >
>> > > I kept the 9.0-alph
>> In hindsight I could have loaded the ASCII release notes into a wiki and
>> people could have modified, them, and later I could have converted them
>> to SGML,
That was, in fact, *exactly* what you said you'd do 3 months ago when we
discussed this.
>
> Yeah, I don't think that would have bee
2010/3/21 Tom Lane :
> Robert Haas writes:
>> I'm not sure that Pavel's idea is the right way to attack the problem,
>> but I don't agree with this either. Line numbers are really the only
>> feasible way of identifying a position in a large function. I usually
>> bring up the function source co
>
> The direction that we ought to be pushing in, I think, is the same as
> the vision for syntax error handling: enable pgAdmin and similar tools
> to pop up the function text with a cursor placed at (more or less) the
> right place. It's interesting to think about how that might be extended
> to
Hello, I'm Joey Adams, and I'm interested in applying for Google
Summer of Code to work on PostgreSQL. I'm a former GSoC student (I
worked on CCAN last year), and a strong C programmer, though I am
still new to working with large, established communities. I apologize
if this is the wrong place to
27 matches
Mail list logo
