[HACKERS] Modifing returning value of PQgetvalue.

[Dmitry Igrishin]

Hello,

PQgetvalue returns a value of type char* (without const). But the
documentation says:
"The pointer returned by PQgetvalue points to storage that is part of the
PGresult structure. *One should not modify the data it points to*" (my
italics). Could someone tell me please, what wrong with modifing arbitrary
character of the data pointed by PQgetvalue's returning value? Or why this
restriction is documented? Thanks.

Re: [HACKERS] [GENERAL] C++ port of Postgres

[Dmitry Igrishin]

2016-08-17 14:40 GMT+03:00 Aleksander Alekseev :
>> I'm sure this wasn't your intent, but the tone of your response is
>> part of why people don't get involved with Postgres development...
>>
>> Please note that you're the only person in the entire thread that's
>> said anything to the effect of a holy war...
>>
>> OTOH, if the community takes the stance of "WTF WHY DO WE NEED
>> THIS?!",  we've just driven Joy and anyone else that's a C++ fan away.
>
> I'm sorry for being maybe to emotional. It's was not (and never is!) my
> intent to offend anyone. Also I would like to note that I don't speak
> for community, I speak for myself.
>
> What I saw was: "hey, lets rewrite PostgreSQL in C++ without any good
> reason except (see [1] list)". Naturally I though (and still think) that
> you people are just trolls. Or maybe "everything should be written in
> C++ because it's the only right language and anyone who thinks
> otherwise is wrong" type of fanatics. Thus I don't think you are here to
> help.
>
> Give a concrete reason. Like "hey, we rewrote this part of code in C++
> and look, its much more readable, twice as fast as code in C (how to do
> benchmarks right is a separate good topic!) and it still compiles fast
> even on Raspberry Pi, works on all platforms you are supporting, etc".
> Or "hey, we solved xid wraparound problem once and for all, but solution
> is in C++, so its for you to decide whether to merge it or not".
I doubt that someone will rush to rewrite PostgreSQL in C++. At now, the
reason to consider the refactoring of current codebase to make the C++
compilers happy, is to make the code more qualitative. I think, that only after
that step it is reasonable to consider the use some of C++ features.


-- 
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] [GENERAL] C++ port of Postgres

[Dmitry Igrishin]

2016-08-16 18:52 GMT+03:00 Heikki Linnakangas :
> On 08/16/2016 05:47 PM, Jim Nasby wrote:
>>
>> I realize there's little technical reason why we *need* C++ support. The
>> level if discipline applied to our codebase negates some of the benefits
>> of C++. But maintaining the discipline takes a lot of time and effort,
>> and makes it more difficult to attract new contributors.
>
>
> I suspect that it would take as much discipline to keep a C++ codebase
> readable, as the current C codebase. If not more.
For example, its easier and less error prone to define structures with
virtual functions in C++ than write vtables manually in C. So, the adequate
subset of the C++ features can be useful to write more readable and
maintainable C-style code. These features are:

  - abstract classes (well, structures with virtual functions);
  - RTTI;
  - lambda functions;
  - constexpr functions;
  - destructors;
  - templates (very reservedly).

But these features should be avoided (as least for now):

  - exceptions;
  - the parts of the standard library which generates exceptions
(in particular, regex and thread).

-- 
// Dmitry.


-- 
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] PATCH: Batch/pipelining support for libpq

[Dmitry Igrishin]

2016-05-24 5:01 GMT+03:00 Craig Ringer :
>
> On 24 May 2016 at 00:00, Michael Paquier  wrote:
>>
>> On Mon, May 23, 2016 at 8:50 AM, Andres Freund  wrote:
>
>
>>
>> > yay^2.
>>
>> I'll follow this mood. Yeha.
>
>
>
> BTW, I've publushed the HTML-ified SGML docs to
> http://2ndquadrant.github.io/postgres/libpq-batch-mode.html as a preview.
Typo detected: "Returns 1 if the batch curently being received" -- "curently".

-- 
// Dmitry.


-- 
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] Deleting prepared statements from libpq.

[Dmitry Igrishin]

2016-05-25 16:50 GMT+03:00 Tom Lane <t...@sss.pgh.pa.us>:

> Dmitry Igrishin <dmit...@gmail.com> writes:
> > "there is no libpq function for deleting a prepared statement".
> > Could you tell me please, what is the reason for this?
>
> You don't really need one, since you can just use DEALLOCATE.
>
Yes, but there are also Parse(F) message, while anybody can just use
PREPARE.

-- 
// Dmitry.

[HACKERS] Deleting prepared statements from libpq.

[Dmitry Igrishin]

Hello,

According to
https://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY
there are Close message for closing prepared statements or portals, but
according to
https://www.postgresql.org/docs/current/static/libpq-exec.html#LIBPQ-PQPREPARE
"there is no libpq function for deleting a prepared statement".

Could you tell me please, what is the reason for this?

-- 
// Dmitry.

Re: [HACKERS] SET SESSION AUTHORIZATION superuser limitation.

[Dmitry Igrishin]

2015-12-21 17:57 GMT+03:00 Tom Lane :

> Robert Haas  writes:
> > On Sun, Dec 20, 2015 at 1:47 PM, Tom Lane  wrote:
> >> The syntax you propose exposes the user's password in cleartext in
> >> the command, where it is likely to get captured in logs for example.
> >> That's not going to do.
>
> > Of course, right now, the ALTER USER ... PASSWORD command has that
> > problem which is, uh, bad.
>
> Which is why we invented the ENCRYPTED PASSWORD syntax, as well as
> psql's \password command ... but using that approach for actual
> login to an account would be a security fail as well.
>
The connection should be secured somehow (SSL/SSH...) to prevent password
thefts. On the other hand, the logging system should not log details of
commands
like ALTER USER ...

[HACKERS] SET SESSION AUTHORIZATION superuser limitation.

[Dmitry Igrishin]

Hackers,

There are feature which may be useful in conjunction with connection pools.
It is the ability to change the session user without creating the new
connection, like this:
(pseudo REPL):
notsuperuser > SELECT current_user, session_user;
notsuperuser notsuperuser
notsuperuser > SET SESSION AUTHORIZATION notsuperuser2 PASSWORD
'password_of_notsuperuser2';
SET SESSION AUTHORIZATION
notsuperuser2 > SELECT current_user, session_user;
notsuperuser2 notsuperuser2
notsuperuser2 > SET ROLE user3;
notsuperuser2 > SELECT current_user, session_user;
user3 notsuperuser2
According to [1], SET SESSION AUTHORIZATION can only be
used by superusers. Is it possible to extend it for use by not only
superusers?

[1]
http://www.postgresql.org/docs/9.4/static/sql-set-session-authorization.html

-- 
// Dmitry.

Re: [HACKERS] SET SESSION AUTHORIZATION superuser limitation.

[Dmitry Igrishin]

2015-12-20 21:47 GMT+03:00 Tom Lane <t...@sss.pgh.pa.us>:

> Dmitry Igrishin <dmit...@gmail.com> writes:
> > There are feature which may be useful in conjunction with connection
> pools.
> > It is the ability to change the session user without creating the new
> > connection, like this:
> > (pseudo REPL):
> > notsuperuser > SELECT current_user, session_user;
> > notsuperuser notsuperuser
> > notsuperuser > SET SESSION AUTHORIZATION notsuperuser2 PASSWORD
> > 'password_of_notsuperuser2';
> > SET SESSION AUTHORIZATION
> > notsuperuser2 > SELECT current_user, session_user;
> > notsuperuser2 notsuperuser2
> > notsuperuser2 > SET ROLE user3;
> > notsuperuser2 > SELECT current_user, session_user;
> > user3 notsuperuser2
> > According to [1], SET SESSION AUTHORIZATION can only be
> > used by superusers. Is it possible to extend it for use by not only
> > superusers?
>
> The syntax you propose exposes the user's password in cleartext in
> the command, where it is likely to get captured in logs for example.
> That's not going to do.

Uh, I'm not propose exactly this syntax. I just used it to explain the idea.
Secondly, there are CREATE ROLE ... [ENCRYPTED] PASSWORD
which can be also captured by logs?..

> It also assumes that the user *has* a password
> that should be honored unconditionally, which is not the case in many
> authentication setups.
>
Not really. Why not just signal an error from SET SESSION AUTHORIZATION
if the target user doesn't has a password?

>
> Also, you have failed to explain why SET ROLE isn't an adequate substitute
> for the cases that would plausibly be allowable to non-superusers.
>
Suppose the role 'web' which is used as a role for pool. SET ROLE is
useless in
this case, since every "guest" can use it to became the any user he/she
wants,
because SET ROLE don't require the password.

>
> Lastly, no connection pool that I would trust would use such a command
> rather than maintaining separate connections for each userid.  There's
> too much risk of security problems from leftover session state.
>
Creating the new (personal) connection for each HTTP request to use the
PostgreSQL's
privileges is too expensive. The feature I'm talking about is some sort of
optimization.


-- 
// Dmitry.

Re: [HACKERS] How to create shared_ptr for PGconn?

[Dmitry Igrishin]

2015-03-16 19:32 GMT+03:00 Chengyu Fan chengyu@hotmail.com:

 Hi,

 Does anyone know how to create the shared_ptr for PGconn? I always get
 compile errors ...

 Below is my code:
 ---
 const char * dbInfo = xxx;
 PGconn *conn = PGconnectdb(dbInfo);
 if (PGstatus(conn) != CONNECTION_OK) {
 std::cout  PQerrorMessage(conn)  std::endl;
 return 1;
 }

 std::shared_ptrPGconn pConn(conn);
 ---

 Error messages for the code above:

 *main.cpp:153:27: **note: *in instantiation of function template
 specialization 'std::__1::shared_ptrpg_conn::shared_ptrpg_conn, void'
 requested here

   std::shared_ptrPGconn pConn(rawConn);


 */usr/local/Cellar/postgresql/9.4.1/include/libpq-fe.h:129:16: note: *forward
 declaration of 'pg_conn'

 typedef struct pg_conn PGconn;

The complete example below:

#include memory

#include libpq-fe.h

int main(int argc, char *argv[])
{
  PGconn* cn = PQconnectdb();
  std::shared_ptrPGconn shared_cn(cn, PQfinish);

  return 0;
}



-- 
// Dmitry.