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 inconsistent, and
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
That would allow for a maximum of 10 exponent digits. As an aside, I
note that int4out() hardcodes the maximum number of digits rather than
exposing a constant (c.f. MAXINT8LEN in int8.c). I'm considering
adding
Brendan Jurd escribió:
Here's version 6 of the patch, now with an all-new implementation
of (normalised) scientific notation in numeric.c, via the functions
numeric_out_sci() and get_str_from_var_sci(). So should now be
able to represent the full gamut of the numeric type.
I
On Sat, 2009-08-08 at 22:02 -0400, Robert Haas wrote:
I think it would also be fair to point out that you keep saying that
you're going to deliver this patch for 8.5, but you haven't provided
any real timetable as to when you're going to start working on it or
when it'll be completed.
Tom Lane wrote:
the function time and the commit time a lot better. But I'm not sure
if the use-case is popular enough to deserve such a hack.
For some OLTP workloads, it makes a lot of sense to spool tuples of
primary key plus new fields into a temp table and then doing a single update
or
Bruce Momjian wrote:
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
Boszormenyi Zoltan írta:
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
Bruce Momjian wrote:
I can just have pg_migrator detect hstore and require it be removed
before upgrading; we did that already for 8.3 to 8.4 and I am assuming
we will continue to have cases there pg_migrator just will not work.
The more things you exclude the less useful the tool
On Sunday 09 August 2009 03:53:55 Andrew Dunstan wrote:
the documentation of psql's --no-readline option was removed
(psql-ref.sgml v 1.23). I think this was a mistake and it should be
restored :-)
Does that option have a point? Should the option be removed, perhaps?
--
Sent via
On Saturday 08 August 2009 01:28:34 Tom Lane wrote:
David Fetter da...@fetter.org 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
Peter Eisentraut wrote:
On Sunday 09 August 2009 03:53:55 Andrew Dunstan wrote:
the documentation of psql's --no-readline option was removed
(psql-ref.sgml v 1.23). I think this was a mistake and it should be
restored :-)
Does that option have a point? Should the option be removed,
Andrew Dunstan and...@dunslane.net writes:
the documentation of psql's --no-readline option was removed
(psql-ref.sgml v 1.23). I think this was a mistake and it should be
restored :-) I'm quite never sure how far back to take pure docs
patches, though. Should I just fix HEAD, or HEAD plus
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at 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
Robert Haas robertmh...@gmail.com writes:
distinct_col_search() is going to return the relevant equality
operator from the argument list, which is ultimately going to come
from the RestrictInfo for the join clause. So I need to see whether
that's compatible with the index, but
Andrew Dunstan wrote:
I can't imagine losing a huge percentage of pg_migrator users via hstore
changes, especially since you can migrate hstore manually and still use
pg_migrator.
We could finesse the hstore issues, but we are already blown out of the
water right now by the enum
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the parameters named
and some not)? ISTM that just serves to complicate both the patch
and the user's-eye view, for no real benefit.
Considering that we are worried about someday
Bruce Momjian wrote:
Andrew Dunstan wrote:
I can't imagine losing a huge percentage of pg_migrator users via hstore
changes, especially since you can migrate hstore manually and still use
pg_migrator.
We could finesse the hstore issues, but we are already blown out of the
On Sun, Aug 9, 2009 at 5:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I am having a hard time wrapping my brain around what it means to have
multiple, incompatible notions of equality... any help appreciated!
Well, for instance a complex-number datatype could have one btree
opclass that sorts on
--On 9. August 2009 12:27:53 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the parameters named
and some not)? ISTM that just serves to complicate both the patch
and the user's-eye
Andrew Dunstan wrote:
Bruce Momjian wrote:
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
Bernd Helmle maili...@oopsware.de writes:
--On 9. August 2009 12:27:53 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the parameters named
and some not)? ISTM that just serves to
On Sat, Aug 08, 2009 at 04:57:57PM -0400, Tom Lane 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
Which was added because most
On Sat, Aug 08, 2009 at 05:29:06PM -0400, Tom Lane wrote:
around nontrivial expressions. So I'd like to see an actual case made
that there's a strong reason for not requiring FROM/IN in ecpg.
I guess there's only one, compatibility.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De,
Michael Meskes mes...@postgresql.org writes:
On Sat, Aug 08, 2009 at 05:29:06PM -0400, Tom Lane wrote:
around nontrivial expressions. So I'd like to see an actual case made
that there's a strong reason for not requiring FROM/IN in ecpg.
I guess there's only one, compatibility.
Yeah. Are
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think it's a lot more nebulous than that. At the same time I think the
days when we can blithely change the on-disk format with hardly a
thought for migration are over. IOW, there's agreement things have to
change, but the
Michael Meskes írta:
On Sat, Aug 08, 2009 at 04:57:57PM -0400, Tom Lane 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
--On 9. August 2009 13:00:07 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Mph. Does Oracle adopt the same semantics for what a mixed call means?
I had a look at the Oracle documentation while reviewing this patch, and i
thought we are pretty close to what they do. Maybe Pavel can comment more
On Sun, Aug 9, 2009 at 12:27 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the parameters named
and some not)? ISTM that just serves to complicate both the patch
and the user's-eye view,
Boszormenyi Zoltan írta:
Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at 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
On Sunday 09 August 2009 17:57:23 Andrew Dunstan wrote:
Peter Eisentraut wrote:
On Sunday 09 August 2009 03:53:55 Andrew Dunstan wrote:
the documentation of psql's --no-readline option was removed
(psql-ref.sgml v 1.23). I think this was a mistake and it should be
restored :-)
Does
Robert Haas robertmh...@gmail.com writes:
On Sun, Aug 9, 2009 at 12:27 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the parameters named
and some not)? ISTM that just serves to complicate
This is a nice section layout for a patch review report --- should we
provide an email template like this one for reviewers to use?
---
Josh Williams wrote:
Teodor, et al,
This is a review of the Polygons patch:
On Sun, Aug 9, 2009 at 2:17 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Aug 9, 2009 at 12:27 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Now that I've started to read this patch ... exactly what is the
argument for allowing a mixed notation (some of the
On Sun, Aug 9, 2009 at 2:20 PM, Bruce Momjianbr...@momjian.us wrote:
This is a nice section layout for a patch review report --- should we
provide an email template like this one for reviewers to use?
We could, but it might be over-engineering. Those particular section
headers might not be
I've now read most of this patch, and I think there are some things that
need rework, and perhaps debate about what we want.
1. As I already mentioned, I think the mixed-notation business is a bad
idea. It's unintuitive, it's not especially useful, and it substantially
increases our risk of
Oh, another thing: the present restriction that all function parameters
after the first one with a default must also have defaults is based on
limitations of positional call notation. Does it make sense to relax
that restriction once we allow named call notation, and if so what
should we do
On Sun, Aug 9, 2009 at 6:11 AM, Simon Riggssi...@2ndquadrant.com wrote:
I'm working on HS; I've said so clearly and say it again now. To my
knowledge, no other Postgres project has committed to a timetable for
delivery, so I'm not clear why you think one should have been given
here, or why the
Robert Haas robertmh...@gmail.com writes:
On Sun, Aug 9, 2009 at 2:17 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I think this patch is an exercise in
guessing at what the SQL committee will eventually do, and as such, we
should avoid like the plague making any guesses that carry significant
risk
On Sun, Aug 09, 2009 at 02:29:44PM -0400, Robert Haas wrote:
On Sun, Aug 9, 2009 at 2:20 PM, Bruce Momjianbr...@momjian.us wrote:
This is a nice section layout for a patch review report --- should we
provide an email template like this one for reviewers to use?
We could, but it might be
Robert Haas robertmh...@gmail.com writes:
Revised patch attached. I'm not convinced this is as good as it can
be, but I've been looking at this patch for so long that I'm starting
to get cross-eyed, and I'd like to Tom at least have a look at this
and assess it before we run out of
On Sat, 2009-08-08 at 13:12 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
I'm not sure why you're stirring this up again.
You stated:
- It's going to be very confusing if people submit their own versions of
- it. So now we have mine, Heikki's and Robert's. I'd like this to stop
-
Simon Riggs wrote:
On Sat, 2009-08-08 at 13:12 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
I'm not sure why you're stirring this up again.
You stated:
- It's going to be very confusing if people submit their own versions of
- it. So now we have mine, Heikki's and
On Sun, Aug 9, 2009 at 3:57 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Revised patch attached. I'm not convinced this is as good as it can
be, but I've been looking at this patch for so long that I'm starting
to get cross-eyed, and I'd like to Tom at least
On Sun, Aug 9, 2009 at 7:30 PM, Tom Lanet...@sss.pgh.pa.us wrote:
1. As I already mentioned, I think the mixed-notation business is a bad
idea. It's unintuitive, it's not especially useful, and it substantially
increases our risk of being semantically incompatible with whatever the
SQL
Josh Berkus wrote:
I disagree here. While it's nice to be MySQL-compatible, a glob * is
not at all consistent with other SQL syntax, whereas ALL and GRANT ON
ALL IN SCHEMA schema are.
The * was reaction to Toms fears of standard adding GRANT ON ALL with
conflicting meaning, but I don't
Hi,
I attached revised version of the patch. Changes, thoughts:
- SCHEMA is mandatory now
- removed VIEWS and GRANT ON VIEW since it looks like only me and
Stephen want it there
- the patch is now made so that adding new filters in the future won't
mean tearing of half of the parser code and
Petr Jelinek wrote:
I attached revised version of the patch. Changes, thoughts:
- SCHEMA is mandatory now
- removed VIEWS and GRANT ON VIEW since it looks like only me and
Stephen want it there
- the patch is now made so that adding new filters in the future won't
mean tearing of half of the
Robert Haas wrote:
The one significant representational choice that I'm aware of having
made is to use nested tags rather than attributes in the XML format.
This seems to me to offer several advantages. First, it's clearly
impossible to standardize on attributes, because attributes can only
On Monday 10 August 2009 01:21:35 Andrew Dunstan wrote:
Robert Haas wrote:
The one significant representational choice that I'm aware of having
made is to use nested tags rather than attributes in the XML format.
This seems to me to offer several advantages. First, it's clearly
Andres Freund wrote:
BTW, has anyone tried validating the XML at all? I just looked very
briefly at the patch at
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01944.php and
I noticed this which makes me suspicious:
+ if (es.format == EXPLAIN_FORMAT_XML)
+
Andrew Dunstan wrote:
Andres Freund wrote:
BTW, has anyone tried validating the XML at all? I just looked very
briefly at the patch at
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01944.php and
I noticed this which makes me suspicious:
+ if (es.format == EXPLAIN_FORMAT_XML)
Andres Freund and...@anarazel.de writes:
On Monday 10 August 2009 01:21:35 Andrew Dunstan wrote:
That ; after the attribute is almost certainly wrong. This is a classic
case of what I was talking about a month or two ago. Building up XML (or
any structured doc, really, XML is not special in
On Monday 10 August 2009 02:48:29 Andrew Dunstan wrote:
Andrew Dunstan wrote:
Andres Freund wrote:
BTW, has anyone tried validating the XML at all? I just looked very
briefly at the patch at
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01944.php and
I noticed this which makes
On Sun, Aug 9, 2009 at 8:48 PM, Andrew Dunstanand...@dunslane.net wrote:
Andrew Dunstan wrote:
Andres Freund wrote:
BTW, has anyone tried validating the XML at all? I just looked very
briefly at the patch at
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01944.php and
I noticed
Andrew Dunstan and...@dunslane.net writes:
I takle it back. It's still there at
http://archives.postgresql.org/pgsql-hackers/2009-08/msg00485.php
posted 3 days ago.
Hmm, I think the archive website must be mangling that somehow.
What I have in the code I'm reviewing is
if (es.format ==
On Sun, Aug 9, 2009 at 9:03 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
I takle it back. It's still there at
http://archives.postgresql.org/pgsql-hackers/2009-08/msg00485.php
posted 3 days ago.
Hmm, I think the archive website must be mangling that
On Sun, Aug 9, 2009 at 8:53 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
On Monday 10 August 2009 01:21:35 Andrew Dunstan wrote:
That ; after the attribute is almost certainly wrong. This is a classic
case of what I was talking about a month or two ago.
On Monday 10 August 2009 02:53:16 Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Monday 10 August 2009 01:21:35 Andrew Dunstan wrote:
That ; after the attribute is almost certainly wrong. This is a
classic case of what I was talking about a month or two ago. Building up
XML
On Sun, Aug 9, 2009 at 2:30 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I've now read most of this patch, and I think there are some things that
need rework, and perhaps debate about what we want.
1. As I already mentioned, I think the mixed-notation business is a bad
idea. It's unintuitive, it's
Andres Freund and...@anarazel.de writes:
Adding the notion of opening a 'empty' Group together with X_OPENCLOSE or
handling of X_OPENING|X_CLOSING would allow to handle empty tags like in
ExplainOneUtility (Notify /).
Yeah, I was just wondering what to do with the Notify / code. I'm
not
On Sun, Aug 9, 2009 at 9:32 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
Adding the notion of opening a 'empty' Group together with X_OPENCLOSE or
handling of X_OPENING|X_CLOSING would allow to handle empty tags like in
ExplainOneUtility (Notify /).
Yeah, I
Robert Haas robertmh...@gmail.com writes:
On Sun, Aug 9, 2009 at 2:30 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'm going to mark the patch Waiting on Author, since it's not close
to being committable until these issues are resolved.
Is it realistic to think that this will be finished and
On Monday 10 August 2009 03:34:36 Robert Haas wrote:
On Sun, Aug 9, 2009 at 9:32 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
Adding the notion of opening a 'empty' Group together with X_OPENCLOSE
or handling of X_OPENING|X_CLOSING would allow to handle
Robert Haas wrote:
One subtle point that isn't documented and probably should be is that
JSON can't support a container that behaves partly like a list and
partly like a hash, as XML can. So for example in XML a Plan tag
could have children like Startup-Cost (one each) and could also have
its
On Sun, Aug 9, 2009 at 9:36 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Aug 9, 2009 at 2:30 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'm going to mark the patch Waiting on Author, since it's not close
to being committable until these issues are
On Sun, 2009-08-09 at 13:27 -0600, Joshua Tolley wrote:
On Sun, Aug 09, 2009 at 02:29:44PM -0400, Robert Haas wrote:
On Sun, Aug 9, 2009 at 2:20 PM, Bruce Momjianbr...@momjian.us wrote:
This is a nice section layout for a patch review report --- should we
provide an email template like
On Monday 10 August 2009 03:43:22 Andres Freund wrote:
On Monday 10 August 2009 03:34:36 Robert Haas wrote:
On Sun, Aug 9, 2009 at 9:32 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
Adding the notion of opening a 'empty' Group together with X_OPENCLOSE
On Sun, Aug 9, 2009 at 10:01 PM, Josh Williamsjoshwilli...@ij.net wrote:
How's that for over-engineering? ;)
Top notch.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Aug 9, 2009 at 2:43 PM, Simon Riggssi...@2ndquadrant.com wrote:
I've said very clearly that I am working on this and it's fairly
laughable to suggest that anybody thought I wasn't. What more should I
do to prove something is active if you won't accept my clearly spoken
word? How did
Tom Lane wrote:
Joe Conway m...@joeconway.com 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.
Agreed. The new pg_migrator 8.4.4 does
After making a lot of tests, state file size is not more than 600B.
In some cases, it reached a maximum of size of 712B and I used such
transactions in my tests.
I think setting the size parameter for this would be a frightfully
difficult problem; the fact that average installations wouldn't
On Mon, Aug 10, 2009 at 2:23 AM, Robert Haasrobertmh...@gmail.com wrote:
2. It doesn't appear that any attention has been given to what happens
if CREATE OR REPLACE FUNCTION is used to change the parameter names of
an existing function. Since the post-analysis representation of parameter
2009/8/9 Alvaro Herrera alvhe...@commandprompt.com:
Brendan Jurd escribió:
Here's version 6 of the patch, now with an all-new implementation
of (normalised) scientific notation in numeric.c, via the functions
numeric_out_sci() and get_str_from_var_sci(). So should now be
able to
On Fri, Jul 17, 2009 at 3:19 AM, Peter Eisentrautpete...@gmx.net wrote:
On Thursday 16 July 2009 22:08:25 Kevin Grittner wrote:
On the admin list there was a request for an application name
column in pg_stat_activity.
http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php
This is
Robert Haas robertmh...@gmail.com writes:
Revised patch attached. I'm not convinced this is as good as it can
be, but I've been looking at this patch for so long that I'm starting
to get cross-eyed, and I'd like to Tom at least have a look at this
and assess it before we run out of
75 matches
Mail list logo
