2013/6/28 Albe Laurenz <laurenz.albe@xxxxxxxxxx>
Dmitriy Igrishin wrote:I'm just brainstorming.
>> Since there can be only one unnamed prepared statement per
>> session, there should be only one such object per connection.
>> It should not get deallocated; maybe it could be private to the
>> connection, which only offers a "parseUnnamed" and "executeUnnamed"
>> mathod.
>
> More precisely, there can be only one uniquely named prepared statement (named
> or unnamed) per session.
> Could you provide a signature of parseUnnamed and executeUnnamed please?
> I don't clearly understand this approach.
I'm thinking of something like
void Connection::prepareUnnamed(const char *query,
int nParams,
const Oid *paramTypes);
and
Result Connection::executeUnnamed(int nParams,
const char * const *paramValues,
const int *paramLengths,
const int *paramFormats,
int resultFormat);
But I'm not saying that this is the perfect solution.
I see. It's more like C-styled design, but not C++.
I mean the problem that you create a prepared statement,
>> If you really want your users to be able to set prepared statement
>> names, you'd have to warn them to be careful to avoid the
>> problem of name collision -- you'd handle the burden to them.
>> That's of course also a possible way, but I thought you wanted
>> to avoid that.
>
> The mentioned burden is already handled by backend which throws
> duplicate_prepared_statement (42P05) error.
then issue "DEALLOCATE stmt_name" create a new prepared statement
with the same name and then use the first prepared statement.
I see. But I see no problem to invalidate localy allocated descriptors
of the remote prepared statements
>>> Prepared_statement* pst1 = connection->describe("name");
>>> Prepared_statement* pst2 = connection->describe("name"); // pst2 points to the same remote
>>> object
>>
>> That seems like bad design to me.That's a different thing, because all these pointers contain the same
>> I wouldn't allow different objects pointing to the same prepared
>> statement. What is the benefit?
>> Shouldn't the model represent reality?
>
> Well, then the C and C++ languages are bad designed too, because they
> allow to have as many pointers to the same as the user like (needs) :-)
value. So if pst1 and pst2 represent the same object, I'd like
pst1 == pst2 to be true.
IOW, you want to map localy allocated object to the remote one.
Or course, it is possible. But I dislike approach, since:
a) objects pointed by pst* should be owned by the Connection instance;
b) these objects may have its own state depending on the application
context (e.g., different valuess binded, result format settings etc etc.)
but it will be impossible due to a).
BTW, according to 18.6.3.1 of "The C++ Programming Language" by Stroustrup,
"The default meaning of < and == for pointers are rarely useful as comparison criteria
for the objects pointed to." So, I believe that you means that you'd like
*pst1 == *pst2. And yes, I'll agree with it.
... but for the same prepared statement.
> Really, I don't see bad design here. Describing prepared statement
> multiple times will results in allocating several independent descriptors.
But those would be two different statement to PostgreSQL, even if the
> (As with, for example, performing two SELECTs will result in allocating
> several independent results by libpq.)
query strings are identical.
Mind you, I'm not saying that I am the person that decides what is
good taste and what not, I'm just sharing my sentiments.
Don't worry, I'm mature enough to understand this :-) And thank you
for you suggestions!
Again, I would say that that is a matter of taste.
>> Of course an error during DEALLOCATE should be ignored in that case.
>> It's hard to conceive of a case where deallocation fails, but the
>> connection is fine. And if the connection is closed, the statement
>> will be deallocated anyway.
>
> Why this error should be ignored? I believe that this should be decided by the user.
> As a library author I don't know (and cannot know) how to react on such errors
> in the end applications.
I just cannot think of a case where this would be important.
Maybe, but I'm firmly belive, that errors, provoked by the user, should
not be ignored at all. This is a one of design principles of my library.
Agreed, it's a matter of taste.
>>> Btw, by the reason 2) there are no any transaction RAII classes as in some other libraries,
>>> because the ROLLBACK command should be executed in the destructor and may throw.
>>
>> I tend to believe that such errors could also be ignored.
>> If ROLLBACK (or anything else) throws an error, the transaction will
>> get rolled back anyway.
>
> Perhaps, but, again, I don't know how the user will prefer to react. So, I prefer just
> to throw and allow the user to decide.
Yours,
Laurenz Albe
// Dmitriy.
