> 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
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
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 26, 2018 at 9:47 AM, Rober
wrote:
> On Fri, Jan 26, 2018 at 10:32 AM, Robert Zenz <robert.z...@sibvisions.com>
> 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
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
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
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
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
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
