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
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)
2010/3/21 Craig Ringer cr...@postnewspapers.com.au:
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
On 21/03/2010 10:33 PM, Pavel Stehule wrote:
2010/3/21 Craig Ringercr...@postnewspapers.com.au:
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)
2010/3/21 Craig Ringer cr...@postnewspapers.com.au:
On 21/03/2010 10:33 PM, Pavel Stehule wrote:
2010/3/21 Craig Ringercr...@postnewspapers.com.au:
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
Andrew Dunstan and...@dunslane.net 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
Pavel Stehule pavel.steh...@gmail.com 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
2010/3/21 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Tom Lane t...@sss.pgh.pa.us 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
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
Dimitri Fontaine dfonta...@hi-media.com 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
Tom Lane t...@sss.pgh.pa.us 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.
2010/3/21 Tom Lane t...@sss.pgh.pa.us:
Dimitri Fontaine dfonta...@hi-media.com 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)
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 gokul...@gmail.com 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
On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com 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)
On Fri, Mar 19, 2010 at 2:09 PM, Gurjeet Singh singh.gurj...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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 section
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 compare them with
On Sun, Mar 21, 2010 at 4:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Sun, Mar 21, 2010 at 6:14 PM, Bruce Momjian br...@momjian.us 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-alpha release
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 been
2010/3/21 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com 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
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
27 matches
Mail list logo
