As David said, you'd be better off having a table that looks like this (in terms
of columns):
* MONTH
* AGENT
* CASHFLOW
So your query to get the sum of a single agent would be looking like:
select
sum(CHASFLOW)
where
AGENT = 'Agent'
and MONTH between values;
> I have a table with 21 columns.
> Primary key is done with 20 of these colums.
Oh, okay. What data types do these encompass?
> I don't know why, but I'm not able to update some of these records.
> I don't understand, it seems that I'm not able to fetch.
You mean you can't query them with all 2
We are seeing a quite heavy slow down when using prepared statements in 10.1.
I haven't done some thorough testing, to be honest, but what we are having is a
select from a view (complexity of it should not matter in my opinion), something
like this:
prepare TEST (text, int) select * from OUR_
On 31.01.2018 19:58, David G. Johnston wrote:
> Now that I've skimmed the tutorial again I think pointing the reader of
> the SQL Commands there to learn how it works in practice is better than
> trying to explain it in BEGIN and/or SAVEPOINT.
That seems like a good idea, yeah.
> I decided to ad
On 30.01.2018 03:07, David G. Johnston wrote:
> So, my first pass at this.
Nice, thank you.
> + These are of particular use for client software to use when executing
> + user-supplied SQL statements and want to provide try/catch behavior
> + where failures are ignored.
Personally, I'd rewor
On 29.01.2018 16:33, Tom Lane wrote:
> That behavior does exist, and so does documentation for it; you're just
> looking in the wrong place.
>
> Years ago (7.3 era, around 2002) we experimented with a server-side
> GUC variable "AUTOCOMMIT", which switched from the implicit-commit-
> if-you-don't-
On 29.01.2018 15:11, Alban Hertroys wrote:
> IMHO, the burden of explaining that is with those RDBMSes that don't
> behave properly:
>
> If you start a transaction and something goes wrong in the process,
> the logical behaviour is to fail - the user will want to rollback to a
> sane state, doing
On 29.01.2018 14:36, David G. Johnston wrote:
> Those questions would not be answered in user-facing documentation. You
> can explore the git history and search the far-back mailing list archives if
> you wish to satisfy your curiosity. For me this is how it works - the only
> question for me is
On 29.01.2018 12:37, Adam Tauno Williams wrote:
> It this statement true? I very much feel *not*. This depends on how
> you have set AUTO_COMMIT - and it certainly is not true for
> transactions of multiple statements.
Maybe I should clarify at that point that AUTO_COMMIT is OFF, and yes, that i
On 26.01.2018 17:11, David G. Johnston wrote:
> The convention for these lists is to inline or bottom-post. Top-posting
> is discouraged.
Okay, I'll keep it in mind.
> Here's my take, the docs support this but maybe take some interpretation...
>
> A SAVEPOINT begins what is effectively a sub-
Melvin Davidson wrote:
> On Fri, Jan 26, 2018 at 10:32 AM, Robert Zenz
> wrote:
>
>> Well, no. What I'm looking for is information on how the transactions
>> behave in
>> an error case, and why there is the requirement to have a savepoint in
>> place to
>>
BACK TO is the only way to regain control of a transaction
block that was put in aborted state by the system due to an error, short of
rolling it back completely and starting again.
and I'm looking on more information on *that*.
On 26.01.2018 15:59, Melvin Davidson wrote:
> On Fri, Jan
I'm currently doing a small writeup of a bug fix in our framework which involves
savepoints in PostgreSQL (JDBC). However, I have a hard time locating the
documentation regarding this. I mean, from what I can extract from various
sources, PostgreSQL requires to use savepoints if one wants to contin
13 matches
Mail list logo
