Re: [HACKERS] Split-up ECPG patches

Tom Lane wrote: >>> 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 there any other precompilers that actively reject FROM/IN > here? If we're just a bit more strict than the

Re: [HACKERS] [PATCH] 2PC state files on shared memory

Michael Paquier writes: > 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 can only say that that demonstrates you didn't test very many cases. It is trivial to generate enormous

Re: [HACKERS] Patch for 8.5, transformationHook

2009/8/9 Jeff Davis : > 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 pa

Re: [HACKERS] machine-readable explain output v4

Tom Lane wrote: Andrew Dunstan writes: I takle it back. It's still there at 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 == EX

Re: [HACKERS] Patch for 8.5, transformationHook

2009/8/9 Alvaro Herrera : > 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 s

Re: [HACKERS] machine-readable explain output v4

Robert Haas 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 CommitFest. Committed after

Re: [HACKERS] pg_stat_activity.application_name

On Fri, Jul 17, 2009 at 3:19 AM, Peter Eisentraut 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 avai

Re: [HACKERS] WIP: to_char, support for EEEE format

2009/8/9 Alvaro Herrera : > 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

Re: [HACKERS] Issues for named/mixed function notation patch

On Mon, Aug 10, 2009 at 2:23 AM, Robert Haas 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 >> lists is still e

Re: [HACKERS] [PATCH] 2PC state files on shared memory

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 u

Re: [HACKERS] change in timestamp output from 8.3 to 8.4

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. Agreed. The new pg_migrator 8.4.4 does clean those

Re: [HACKERS] hot standby - merged up to CVS HEAD

On Sun, Aug 9, 2009 at 2:43 PM, Simon Riggs 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 you decide I was i

Re: [HACKERS] Review: Patch for contains/overlap of polygons

On Sun, Aug 9, 2009 at 10:01 PM, Josh Williams 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

Re: [HACKERS] machine-readable explain output v4

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 Lane wrote: > > > Andres Freund writes: > > >> Adding the notion of opening a 'empty' Group together with X_OPENCLOSE > > >> or handling of X_OPENIN

Re: [HACKERS] Review: Patch for contains/overlap of polygons

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 Momjian wrote: > > > This is a nice section layout for a patch review report --- should we > > > provide an email template like this one f

Re: [HACKERS] Issues for named/mixed function notation patch

On Sun, Aug 9, 2009 at 9:36 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Aug 9, 2009 at 2:30 PM, Tom Lane 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

Re: [HACKERS] machine-readable explain output v4

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 tag could have children like (one each) and could also have its inner, outer, an

Re: [HACKERS] machine-readable explain output v4

On Monday 10 August 2009 03:34:36 Robert Haas wrote: > On Sun, Aug 9, 2009 at 9:32 PM, Tom Lane wrote: > > Andres Freund 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 Explain

Re: [HACKERS] Issues for named/mixed function notation patch

Robert Haas writes: > On Sun, Aug 9, 2009 at 2:30 PM, Tom Lane 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 committed this week? I didn't want to pr

Re: [HACKERS] machine-readable explain output v4

On Sun, Aug 9, 2009 at 9:32 PM, Tom Lane wrote: > Andres Freund 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 (). > > Yeah, I was just wondering what to do with t

Re: [HACKERS] machine-readable explain output v4

Andres Freund 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 (). Yeah, I was just wondering what to do with the code. I'm not sure if it's worth trying to fold i

Re: [HACKERS] Issues for named/mixed function notation patch

On Sun, Aug 9, 2009 at 2:30 PM, Tom Lane 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 not especially

Re: [HACKERS] machine-readable explain output v4

On Monday 10 August 2009 02:53:16 Tom Lane wrote: > Andres Freund 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 an

Re: [HACKERS] machine-readable explain output v4

On Sun, Aug 9, 2009 at 8:53 PM, Tom Lane wrote: > Andres Freund 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 stru

Re: [HACKERS] machine-readable explain output v4

On Sun, Aug 9, 2009 at 9:03 PM, Tom Lane wrote: > Andrew Dunstan writes: >> I takle it back. It's still there at >> >> posted 3 days ago. > > Hmm, I think the archive website must be mangling that somehow. > What I have in the cod

Re: [HACKERS] machine-readable explain output v4

Andrew Dunstan writes: > I takle it back. It's still there at > > 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 == EXPLAIN_FORMAT_

Re: [HACKERS] machine-readable explain output v4

On Sun, Aug 9, 2009 at 8:48 PM, 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 and >>>

Re: [HACKERS] machine-readable explain output v4

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 > >>> and > >>> I noti

Re: [HACKERS] machine-readable explain output v4

Andres Freund 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 this regard)

Re: [HACKERS] machine-readable explain output v4

Andrew Dunstan wrote: Andres Freund wrote: BTW, has anyone tried validating the XML at all? I just looked very briefly at the patch at and I noticed this which makes me suspicious: + if (es.format == EXPLAIN_FORMAT_XML)

Re: [HACKERS] machine-readable explain output v4

Andres Freund wrote: BTW, has anyone tried validating the XML at all? I just looked very briefly at the patch at and I noticed this which makes me suspicious: + if (es.format == EXPLAIN_FORMAT_XML) + append

Re: [HACKERS] machine-readable explain output v4

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 > > i

Re: [HACKERS] machine-readable explain output v4

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 be

Re: [HACKERS] GRANT ON ALL IN schema

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 pa

Re: [HACKERS] GRANT ON ALL IN schema

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 re

Re: [HACKERS] GRANT ON ALL IN schema

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 " are. The * was reaction to Toms fears of standard adding GRANT ON ALL with conflicting meaning, but I don't reall

Re: [HACKERS] Issues for named/mixed function notation patch

On Sun, Aug 9, 2009 at 7:30 PM, Tom Lane 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 committee might somed

Re: [HACKERS] machine-readable explain output v4

On Sun, Aug 9, 2009 at 3:57 PM, Tom Lane wrote: > Robert Haas 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 asses

Re: [HACKERS] hot standby - merged up to CVS HEAD

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,

Re: [HACKERS] hot standby - merged up to CVS HEAD

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 t

Re: [HACKERS] machine-readable explain output v4

Robert Haas 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 CommitFest. I'm starting to

Re: [HACKERS] Review: Patch for contains/overlap of polygons

On Sun, Aug 09, 2009 at 02:29:44PM -0400, Robert Haas wrote: > On Sun, Aug 9, 2009 at 2:20 PM, Bruce Momjian 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-enginee

Re: [HACKERS] mixed, named notation support

Robert Haas writes: > On Sun, Aug 9, 2009 at 2:17 PM, Tom Lane 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 of being semantically incompatib

Re: [HACKERS] hot standby - merged up to CVS HEAD

On Sun, Aug 9, 2009 at 6:11 AM, Simon Riggs 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 absence of such a

Re: [HACKERS] Issues for named/mixed function notation patch

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 exactl

[HACKERS] Issues for named/mixed function notation patch

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 being

Re: [HACKERS] Review: Patch for contains/overlap of polygons

On Sun, Aug 9, 2009 at 2:20 PM, Bruce Momjian 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 applicable to some

Re: [HACKERS] mixed, named notation support

On Sun, Aug 9, 2009 at 2:17 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Aug 9, 2009 at 12:27 PM, Tom Lane 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 ju

Re: [HACKERS] Review: Patch for contains/overlap of polygons

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: > htt

Re: [HACKERS] mixed, named notation support

Robert Haas writes: > On Sun, Aug 9, 2009 at 12:27 PM, Tom Lane 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

Re: [HACKERS] a short trip in the wayback machine

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 :-)

Re: [HACKERS] Split-up ECPG patches

Boszormenyi Zoltan írta: > 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 v

Re: [HACKERS] mixed, named notation support

On Sun, Aug 9, 2009 at 12:27 PM, Tom Lane 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, for no real be

Re: [HACKERS] mixed, named notation support

--On 9. August 2009 13:00:07 -0400 Tom Lane 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 it. Because

Re: [HACKERS] Split-up ECPG patches

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

Re: [HACKERS] Alpha releases: How to tag

Tom Lane wrote: > Andrew Dunstan 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 exact shape o

Re: [HACKERS] Split-up ECPG patches

Michael Meskes 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 there any other p

Re: [HACKERS] Split-up ECPG patches

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, M

Re: [HACKERS] Split-up ECPG patches

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 mo

Re: [HACKERS] mixed, named notation support

Bernd Helmle writes: > --On 9. August 2009 12:27:53 -0400 Tom Lane 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

Re: [HACKERS] revised hstore patch

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. Th

Re: [HACKERS] mixed, named notation support

--On 9. August 2009 12:27:53 -0400 Tom Lane 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, for no real be

Re: [HACKERS] join removal

On Sun, Aug 9, 2009 at 5:19 PM, Tom Lane 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 absolute v

Re: [HACKERS] revised hstore patch

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

Re: [HACKERS] mixed, named notation support

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 hav

Re: [HACKERS] revised hstore patch

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

Re: [HACKERS] join removal

Robert Haas 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 equality_ops_are_compatible() > w

Re: [HACKERS] Split-up ECPG patches

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

Re: [HACKERS] a short trip in the wayback machine

Andrew Dunstan 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 8.4, or all the

Re: [HACKERS] a short trip in the wayback machine

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,

Re: [HACKERS] Alpha releases: How to tag

On Saturday 08 August 2009 01:28:34 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 developmen

Re: [HACKERS] a short trip in the wayback machine

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 pgsql-hac

Re: [HACKERS] revised hstore patch

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

Re: [HACKERS] Split-up ECPG patches

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 >>> id

Re: [HACKERS] revised hstore patch

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 dec

Re: [HACKERS] slow commits with heavy temp table usage in 8.4.0

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

Re: [HACKERS] hot standby - merged up to CVS HEAD

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. Be

Re: [HACKERS] WIP: to_char, support for EEEE format

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 no

Re: [HACKERS] WIP: to_char, support for EEEE format

2009/8/9 Tom Lane : > Brendan Jurd 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 MAXINT2LEN and MAXINT4LEN to