On Fri, 2009-10-09 at 00:15 +0100, Simon Riggs wrote:
> On Thu, 2009-10-08 at 12:21 -0400, Tom Lane wrote:
> >
> > You'd eat a sub-sub-transaction per row, and start a new sub-transaction
> > every 2^32 rows.
> >
> > However, on second thought this really doesn't get us anywhere, it just
> > move
Zdenek Kotala wrote:
You can look on
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_moth&dt=2009-10-07%2021:06:00
How it is built. You also does not needed own version of Openssl. All
security fixes are backported. It is located in /usr/sfw/lib or
/usr/sfw/lib/64
Sometimes are p
On Fri, 2009-10-09 at 02:23 +0300, Peter Eisentraut wrote:
> INSERT INTO tab1 SELECT ... FROM tab1
>
> clearly requires the SELECT to be distinctly before the INSERT.
That's effectively only one thing: assigning a relation (the result of
the select) to a variable (tab1). I was talking about multi
On Thu, 2009-10-08 at 12:49 +0100, Simon Riggs wrote:
> I'll get cracking on some changes.
This will probably be next week now, just in case you're wondering when
I'll start adding patches.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Thu, 2009-10-08 at 12:21 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Oct 8, 2009 at 11:50 AM, Tom Lane wrote:
> >> I wonder whether we could break down COPY into sub-sub
> >> transactions to work around that...
>
> > How would that work? Don't you still need to increment the com
On Thu, 2009-10-08 at 18:23 -0400, Bruce Momjian wrote:
> Dimitri Fontaine wrote:
> > Simon Riggs writes:
> > > It will be best to have the ability to have a specific rejection reason
> > > for each row rejected. That way we will be able to tell the difference
> > > between uniqueness violation er
On Thu, 2009-10-08 at 12:34 -0700, Jeff Davis wrote:
> I'm still trying to ponder the consequences of this. Most people
> assume
> that a single statement means that everything in the statement happens
> at once (intuitively). The few cases where that's not true are special
> commands or things tha
Robert Haas wrote:
> > That was a compliment on your project management skills. ?Keeping the CF
> > work moving forward steadily is both unglamorous and extremely valuable, and
> > I don't think anyone else even understands why you've volunteered to handle
> > so much of it. ?But I know I appreciat
Robert Haas wrote:
> Each of those features deserves a separate discussion to decide
> whether we want it and how best to implement it. Personally, I think
> we should skip (C), at least as a starting point. Instead of logging
> to a table, I think we should consider making COPY return the tuples
Bruce Momjian wrote:
What would be _cool_ would be to add the ability to have comments in the
COPY files, like \#, and then the copy data lines and errors could be
adjacent. (Because of the way we control COPY escaping, adding \# would
not be a problem. We have \N for null, for example.)
Marko Tiikkaja writes:
> Tom Lane wrote:
>> Hm, I've not compared the two versions of the patch, but what I was
>> thinking was that I'd like to get the resultRelation stuff out of EState
>> and have it *only* in the DML nodes. It sounds like you went in the
>> other direction --- what was the re
Dimitri Fontaine wrote:
> Simon Riggs writes:
> > It will be best to have the ability to have a specific rejection reason
> > for each row rejected. That way we will be able to tell the difference
> > between uniqueness violation errors, invalid date format on col7, value
> > fails check constrain
Tom Lane wrote:
Hm, I've not compared the two versions of the patch, but what I was
thinking was that I'd like to get the resultRelation stuff out of EState
and have it *only* in the DML nodes. It sounds like you went in the
other direction --- what was the reason for that?
I've taken a compro
Marko Tiikkaja writes:
> Sorry for the delay, my master was a bit behind :-( . I moved the
> trigger code to nodeDml.c with minor changes and removed unused
> resultRelation stuff from DML nodes completely. This also has the
> README stuff in it.
Hm, I've not compared the two versions of the pa
On Thu, 2009-10-08 at 13:00 -0400, Greg Smith wrote:
> Perl is the best tool available that runs on the buildfarm, which makes
> something written in it useful here, while Tsung is not. Unfortunately.
But you're not going to do performance testing on the buildfarm anyway.
--
Sent via pgsql-ha
Marko Tiikkaja writes:
> I'm sorry, it didn't occur to me that this is part of this patch, but I
> made these changes in my writeable CTE repo, see
> http://git.postgresql.org/gitweb?p=writeable_cte.git;a=commitdiff;h=41ad3d24af845c67a3866e0946129cf9809fe7e9
Could you pull out a patch that includ
I'm thinking about removing IncrRetrieved(), IncrAppended(), etc
altogether. That code's been dead for a long time, and it's one
of the minor details cluttering the nodeDml patch. Can anyone
see any likelihood of wanting it some day? AFAICS the explain
infrastructure has completely superseded th
Tom Lane wrote:
I was going to look at it and probably do it myself unless it turns out
to be a bigger change than I'm thinking. The only other stuff that's
Ready for Committer for me now is privileges stuff, which is not on the
critical path for other development work, and besides I'm a bit tir
On Thu, Oct 8, 2009 at 4:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> That seems like a good design. I hate to have you spend too much time
>> on any one patch at this stage of the game, though. Is this a big
>> enough change that we should send it back for the patch author (or
>> other inte
Robert Haas writes:
> That seems like a good design. I hate to have you spend too much time
> on any one patch at this stage of the game, though. Is this a big
> enough change that we should send it back for the patch author (or
> other interested parties) to do make that change, or are you just
On Thu, Oct 8, 2009 at 4:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane wrote:
>>> While we're discussing explain output ... what about triggers?
>>> An important aspect of this change is that at least the row-level
>>> triggers are now going to be charg
On Thu, Oct 8, 2009 at 3:53 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Robert Haas escribió:
>>> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane wrote:
I notice also that the patch has chosen to represent Dml in XML/JSON
explain output as Node Type = Dml with an entirely new attribute
>>
On Tue, 22 Sep 2009, Michael Paquier wrote:
The function doCustom is defined with a void.
I see this in pgbench.c:
/* return false iff client should be disconnected */
static bool
doCustom(CState *st, instr_time *conn_time)
I think you need to increase the verbosity of the error messag
Robert Haas writes:
> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane wrote:
>> While we're discussing explain output ... what about triggers?
>> An important aspect of this change is that at least the row-level
>> triggers are now going to be charged as runtime of the
>> Dml-or-whatever-we-call-it node
Alvaro Herrera writes:
> Robert Haas escribió:
>> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane wrote:
>>> I notice also that the patch has chosen to represent Dml in XML/JSON
>>> explain output as Node Type = Dml with an entirely new attribute
>>> Operation to indicate Insert/Update/Delete. Do we re
Robert Haas escribió:
> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane wrote:
> > I notice also that the patch has chosen to represent Dml in XML/JSON
> > explain output as Node Type = Dml with an entirely new attribute
> > Operation to indicate Insert/Update/Delete. Do we really want to
> > go there?
On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane escribió:
>> Does it affect how is it going to look in EXPLAIN output?
>
> Hmm, I suppose there's not any law that says EXPLAIN has to print the
> same name we use internally. The explain output could say "Inser
On Thu, 2009-10-08 at 15:11 -0400, Tom Lane wrote:
> > I'm not sure if this is a problem, but it seems like we're essentially
> > allowing a complex transaction to take place in one statement. Is that
> > what we want?
>
> Yeah, I think that's more or less the point ...
I'm still trying to ponder
Alvaro Herrera writes:
> Tom Lane escribió:
> Does it affect how is it going to look in EXPLAIN output?
Hmm, I suppose there's not any law that says EXPLAIN has to print the
same name we use internally. The explain output could say "Insert",
"Update", or "Delete" independently of what we call th
Le 8 oct. 2009 à 19:00, Greg Smith a écrit :
Perl is the best tool available that runs on the buildfarm, which
makes something written in it useful here, while Tsung is not.
Unfortunately.
I though we were talking about 2 separate issues here: david's one,
for concurrent regression testi
Jeff Davis writes:
> On Thu, 2009-10-08 at 12:57 -0400, Tom Lane wrote:
>> I also agree with bumping the CID in between.
> Do you mean bump the CID in between each DML statement, or between the
> last DML statement and the main query? If the former, how should we
> choose the order of execution?
Tom Lane wrote:
Does anyone have a problem with the ModifyTable suggestion,
or a better idea?
Lacking a better idea, +1 for ModifyTable from me.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
Tom Lane escribió:
> I wrote:
> > Alvaro Herrera writes:
> >> BTW what was the conclusion of the idea about having three separate
> >> nodes Insert, Delete, Update instead of a single Dml node?
>
> > If we stick with a single node type then I'd suggest calling it
> > something like ModifyTable.
>
On Thu, 2009-10-08 at 12:57 -0400, Tom Lane wrote:
> I also agree with bumping the CID in between.
Do you mean bump the CID in between each DML statement, or between the
last DML statement and the main query? If the former, how should we
choose the order of execution?
I'm not sure if this is a pr
I wrote:
> Alvaro Herrera writes:
>> BTW what was the conclusion of the idea about having three separate
>> nodes Insert, Delete, Update instead of a single Dml node?
> If we stick with a single node type then I'd suggest calling it
> something like ModifyTable.
I'm starting to work on this patc
On Thu, Oct 8, 2009 at 1:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 8, 2009 at 12:21 PM, Tom Lane wrote:
>>> Another approach that was discussed earlier was to divvy the rows into
>>> batches. Say every thousand rows you sub-commit and start a new
>>> subtransaction. Up to tha
2009/10/8 David E. Wheeler :
> On Oct 7, 2009, at 9:00 PM, Steve Prentice wrote:
>
>>> Committed with a fair amount of corner-case cleanup and refactoring.
>>
>> Woot! Thanks for all the hard work getting this committed (Pavel, Bernd,
>> Jeff, Tom and others)! I've been really looking forward to th
Robert Haas writes:
> On Thu, Oct 8, 2009 at 12:21 PM, Tom Lane wrote:
>> Another approach that was discussed earlier was to divvy the rows into
>> batches. Say every thousand rows you sub-commit and start a new
>> subtransaction. Up to that point you save aside the good rows somewhere
>> (mayb
"David E. Wheeler" writes:
> On Oct 8, 2009, at 9:47 AM, Jeff Davis wrote:
>> It's just the call notation -- the function only needs to know what
>> arguments it got for which parameters.
> So they're still ordered? I'm thinking of PL/Perl here
It's PL-independent as far as I know --- if you fi
On Thu, 8 Oct 2009, Rod Taylor wrote:
1) Having copy remember which specific line caused the error. So it can
replace lines 1 through 487 in a subtransaction since it knows those are
successful. Run 488 in its on subtransaction. Run 489 through ... in a
new subtransaction.
This is the standa
On Thu, 2009-10-08 at 13:00 -0400, Greg Smith wrote:
> On Thu, 8 Oct 2009, Dimitri Fontaine wrote:
>
> > sorry guys, perl is not made for concurrent programming, it's not going
> > to be easy reaching current tsung level (years of work with ad-hoc
> > tools) using a general hobbyist programming
On Thu, 8 Oct 2009, Tom Lane wrote:
It may be that we should just say "if you want to import dirty data,
it's gonna cost ya" and not worry about the speed penalty of
subtransaction-per-row.
This goes along with the response I gave on objections to adding other
bits of overhead into COPY. If
On Thu, 8 Oct 2009, Dimitri Fontaine wrote:
sorry guys, perl is not made for concurrent programming, it's not going
to be easy reaching current tsung level (years of work with ad-hoc
tools) using a general hobbyist programming language.
Perl is the best tool available that runs on the buildfa
Marko Tiikkaja writes:
> Robert Haas wrote:
>> This has one MAJOR disadvantage: all the tuples from the CTE queries
>> have to be buffered someplace, rather than streamed from the subquery
>> up to the main query. For what may turn out to be pretty common uses
>> cases like WITH tuples AS (DELETE
On Oct 8, 2009, at 9:47 AM, Jeff Davis wrote:
It's just the call notation -- the function only needs to know what
arguments it got for which parameters.
So they're still ordered? I'm thinking of PL/Perl here…
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, Oct 8, 2009 at 12:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 8, 2009 at 11:50 AM, Tom Lane wrote:
>>> I wonder whether we could break down COPY into sub-sub
>>> transactions to work around that...
>
>> How would that work? Don't you still need to increment the command c
Tom Lane wrote:
> Hmm, if we were willing to break COPY into multiple *top level*
> transactions, that would avoid my concern about XID wraparound.
> The issue here is that if the COPY does eventually fail (and there
> will always be failure conditions, eg out of disk space), then some
> of the
On Thu, 2009-10-08 at 09:44 -0700, David E. Wheeler wrote:
> +1 Thanks for getting this done.
>
> Now, does this just apply to PL/pgSQL? If so, what needs to happen for
> other PLs to support the feature?
It's just the call notation -- the function only needs to know what
arguments it got for w
On Thu, Oct 8, 2009 at 12:37 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> Couldn't you just commit each range of subtransactions based on some
>> threshold?
>
>> COPY foo from '/tmp/bar/' COMMIT_THRESHOLD 100;
>
>> It counts to 1mil, commits starts a new transaction. Yes there would be
On Oct 7, 2009, at 9:00 PM, Steve Prentice wrote:
Committed with a fair amount of corner-case cleanup and refactoring.
Woot! Thanks for all the hard work getting this committed (Pavel,
Bernd, Jeff, Tom and others)! I've been really looking forward to
this feature. Still hoping a solution i
"Joshua D. Drake" writes:
> Couldn't you just commit each range of subtransactions based on some
> threshold?
> COPY foo from '/tmp/bar/' COMMIT_THRESHOLD 100;
> It counts to 1mil, commits starts a new transaction. Yes there would be
> 1million sub transactions but once it hits those clean,
Merlin Moncure writes:
> On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas wrote:
>> up to the main query. For what may turn out to be pretty common uses
>> cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
>> INSERT INTO big_table_2 ... this is going to suck pretty bad. I
> Is the a
Tom Lane wrote:
> One thing that would be worth checking before you expend too much
> manual effort on that is whether pg_indent will convert one style
> to the other. Offhand I don't recall that it does, but if it did
> then it'd undo your work ...
No, it doesn't, unless the comment doesn't fit
Dan Colish writes:
> I'm going through a few files and trying to clean them up for style mostly
> and a
> bit of refactoring. I am curious about the preferred style for a one line
> comment. I see them in both of these forms and I would like to keep it
> consistent.
> /* a one line comment */
>
Robert Haas writes:
> On Thu, Oct 8, 2009 at 11:50 AM, Tom Lane wrote:
>> I wonder whether we could break down COPY into sub-sub
>> transactions to work around that...
> How would that work? Don't you still need to increment the command counter?
Actually, command counter doesn't help because i
> Yeah. I think it's going to be hard to make this work without having
> standalone transactions. One idea would be to start a subtransaction,
> insert tuples until one fails, then rollback the subtransaction and
> start a new one, and continue on until the error limit is reached.
>
I've found p
On Thu, 2009-10-08 at 11:59 -0400, Robert Haas wrote:
> On Thu, Oct 8, 2009 at 11:50 AM, Tom Lane wrote:
> >> Another possible approach, which isn't perfect either, is the idea of
> >> allowing COPY to generate a single column of output of type text[].
> >> That greatly reduces the number of possi
On Thu, Oct 08, 2009 at 11:54:08AM -0400, Merlin Moncure wrote:
> On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas wrote:
> > up to the main query. For what may turn out to be pretty common uses
> > cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
> > INSERT INTO big_table_2 ... this
I'm going through a few files and trying to clean them up for style mostly and a
bit of refactoring. I am curious about the preferred style for a one line
comment. I see them in both of these forms and I would like to keep it
consistent.
/* a one line comment */
or
/*
* a one line comment
*/
On Thu, Oct 8, 2009 at 11:50 AM, Tom Lane wrote:
>> Another possible approach, which isn't perfect either, is the idea of
>> allowing COPY to generate a single column of output of type text[].
>> That greatly reduces the number of possible error cases, and at least
>> gets the data into the DB whe
On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas wrote:
> up to the main query. For what may turn out to be pretty common uses
> cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
> INSERT INTO big_table_2 ... this is going to suck pretty bad. I
Is the above form:
with x as (delete .
Robert Haas writes:
> Subcommitting every single row is going to be really painful,
> especially after Hot Standby goes in and we have to issue a WAL record
> after every 64 subtransactions (AIUI).
Yikes ... I had not been following that discussion, but that sure sounds
like a deal-breaker. For
On Thu, Oct 08, 2009 at 10:28:53AM +0200, Dimitri Fontaine wrote:
> http://tsung.erlang-projects.org/
> http://tsung.erlang-projects.org/user_manual.html
> http://archives.postgresql.org/pgsql-admin/2008-12/msg00032.php
It looks like we're talking about two orthogonal projects here:
1. Test s
On Thu, Oct 8, 2009 at 11:29 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> Some defective part of my brain enjoys seeing things run smoothly more
>> than it enjoys being lazy.
>
> Strangely, that seems to say you'd make a bad Perl programmer, per Larry
> Wall's three virtues.
Don't worry
On Thu, Oct 8, 2009 at 11:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> Lest there be any unclarity, I am NOT trying to shoot down this
>> feature with my laser-powered bazooka.
>
> Well, if you need somebody to do that
Well, I'm trying not to demoralize people who have put in hard work,
howev
Robert Haas escribió:
> Some defective part of my brain enjoys seeing things run smoothly more
> than it enjoys being lazy.
Strangely, that seems to say you'd make a bad Perl programmer, per Larry
Wall's three virtues.
--
Alvaro Herrerahttp://www.CommandPrompt.co
Robert Haas writes:
> Lest there be any unclarity, I am NOT trying to shoot down this
> feature with my laser-powered bazooka.
Well, if you need somebody to do that --- I took a quick look through
this patch, and it is NOT going to get committed. Not in anything
approximately like its current fo
On Oct 7, 2009, at 7:41 PM, Tom Lane wrote:
Pavel Stehule writes:
[ latest named-args patch ]
Committed with a fair amount of corner-case cleanup and refactoring.
Woot! Thanks for all the hard work getting this committed (Pavel,
Bernd, Jeff, Tom and others)! I've been really looking forwa
You can look on
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ghost_moth&dt=2009-10-07%2021:06:00
How it is built. You also does not needed own version of Openssl. All
security fixes are backported. It is located in /usr/sfw/lib or
/usr/sfw/lib/64
Sometimes are problem with gcc and sola
On Thu, 2009-10-08 at 08:57 +1100, Brendan Jurd wrote:
> What's the current status of this patch in the commitfest process?
I'm working on it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
Robert Haas wrote:
> It seems quite odd to me that when COPY succeeds but there are
> errors, the transaction commits. The only indication that some of
> my data didn't end up in the table is that the output says "COPY n"
> where n is less than the total number of rows I attempted to copy.
>
Robert Haas writes:
> I have not looked at your patches and am not familiar with ECPG, but I
> wonder if part of the issue here is that there are too many
> interrelated changes. Maybe you'd be better off submitting some
> smaller changes, wait to see how they get committed, and then move on
> to
On Thu, Oct 8, 2009 at 8:34 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> I'm a little mystified by this response since I spent several
>> paragraphs following the one that you have quoted here explaining how
>> I think we should approach the problem of providing the features that
>> are c
I wrote:
3)WITH t1 AS
(UPDATE foo SET bar=bar+1 RETURNING *),
t2 AS
(UPDATE baz SET bat=bat+1 RETURNING *)
VALUES (true);
This isn't probably the most common situation either, but I think it's
worth looking at; the user wants to update two different tables, but
ignore the RET
Robert Haas writes:
> I'm a little mystified by this response since I spent several
> paragraphs following the one that you have quoted here explaining how
> I think we should approach the problem of providing the features that
> are currently all encapsulated under the mantle of "error logging".
On Wed, 2009-10-07 at 22:30 -0400, Robert Haas wrote:
> On Fri, Sep 25, 2009 at 10:01 AM, Emmanuel Cecchet wrote:
> > Robert,
> >
> > Here is the new version of the patch that applies to CVS HEAD as of this
> > morning.
> >
> > Emmanuel
>
> I took a look at this patch tonight and, having now rea
On Thu, Oct 8, 2009 at 7:15 AM, Boszormenyi Zoltan wrote:
> It's easier to write the documentation for all changes at once.
> I would have the same situation that happened with the code,
> the patches with the documentation added would strictly depend
> on each other again. Also, Michael Meskes ap
On Thu, 2009-10-08 at 07:33 -0400, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I would still like you to make a clear statement that the contents of
> > that repository are BSD licenced open source contributions.
>
> Ok. All the content in the repository at
> git://git.postgresql.org/git/u
Simon Riggs wrote:
> I would still like you to make a clear statement that the contents of
> that repository are BSD licenced open source contributions.
Ok. All the content in the repository at
git://git.postgresql.org/git/users/heikki/postgres.git is released under
the same BSD license as Postgre
Robert Haas írta:
> On Thu, Oct 8, 2009 at 6:22 AM, Boszormenyi Zoltan wrote:
>
>> Noah Misch írta:
>>
>>> I will report on the sqlda patch in more detail on
>>> 2009-10-10.
>>>
>> I am attaching a new one, please review this. Changes:
>> - set sqllen, sqlind, sqlilen and sqlitype p
sfr...@snowman.net (Stephen Frost) writes:
> * David Fetter (da...@fetter.org) wrote:
>> On Sun, Oct 04, 2009 at 04:07:40PM -0400, Robert Haas wrote:
>> > > The radical proposal was the RULE system. It's been tested now,
>> > > and it's pretty much failed.
>> >
>> > You still haven't explained w
Robert Haas wrote:
This has one MAJOR disadvantage: all the tuples from the CTE queries
have to be buffered someplace, rather than streamed from the subquery
up to the main query. For what may turn out to be pretty common uses
cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
INS
On Wed, Oct 7, 2009 at 5:08 PM, Marko Tiikkaja
wrote:
> I've made progress in implementing writeable CTEs (repo at
> git://git.postgresql.org/git/writeable_cte.git , branch actually_write)
> and I've hit a few corner-cases which have lead me to think that we
> should be handling DML inside CTEs a
On Thu, Oct 8, 2009 at 6:22 AM, Boszormenyi Zoltan wrote:
> Noah Misch írta:
>> I will report on the sqlda patch in more detail on
>> 2009-10-10.
>
> I am attaching a new one, please review this. Changes:
> - set sqllen, sqlind, sqlilen and sqlitype per-field properties
> - SQLINT8 and SQLSERIAL8
On Thu, Oct 8, 2009 at 4:42 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> What's really bad about this is that a flag called "error_logging" is
>> actually changing the behavior of the command in a way that is far
>> more dramatic than (and doesn't actually have much to do with) error
>> l
Robert Haas writes:
> What's really bad about this is that a flag called "error_logging" is
> actually changing the behavior of the command in a way that is far
> more dramatic than (and doesn't actually have much to do with) error
> logging. It's actually making a COPY command succeed that would
Andrew Dunstan writes:
> Last time I built something to drive a huge client load (many
> thousands of simultaneous connections to a web app) I did it in highly
> threaded Java using HttpUnit from a number of separate client machines. You
> wouldn't believe what that managed to do to MySQL on the
Greg Smith writes: > The stuff I've been
building lately takes "how many sessions at once?" as an > input,
and the useful range on that (particularly as we wander further >
toward multi-core land) is much higher than you'd want to manage
one at a > time manually. I'd rather see a "session sim
Hello,
this proposal is related to discuss about enhancing "any" type and
using this type in other PL than C. Result from this discuss was:
* add synonym for type "any" ~ ANY TYPE
* add possibility select type from other referenced type ~ "TYPE AS
variable (This syntax is impossible, but we can us
On Wed, 2009-10-07 at 23:19 -0400, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > I've made public the version I'm working on. That's the version I'm
> > ultimately going to commit. It would be a lot more helpful if you
> > provided these patches over that version. Otherwise I have to r
90 matches
Mail list logo
