2014-09-22 10:42 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com:
Hello,
a psycopg user is reporting [1] that the library is not marking the
connection as closed and/or bad after certain errors, such as a
connection timeout. He is emulating the error by closing the
connection fd (I
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com:
On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin dmit...@gmail.com
wrote:
2014-09-22 10:42 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com
:
[2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f
Why
2014-09-22 12:36 GMT+04:00 Marko Tiikkaja ma...@joh.to:
On 9/22/14 9:45 AM, Dmitriy Igrishin wrote:
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo daniele.varra...@gmail.com:
On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Why are you using close() instead
2013/7/9 Merlin Moncure mmonc...@gmail.com
On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou ibob...@gmail.com wrote:
Hi, guys! I made a quick patch to support floating number in
connect_timeout param for libpq. This will treat floating number as
seconds so this is backwards-compatible. I don't
2013/6/21 Albe Laurenz laurenz.a...@wien.gv.at
Dmitriy Igrishin wrote:
Sent: Thursday, June 20, 2013 5:09 PM
To: PostgreSQL Hackers
Subject: [HACKERS] Frontend/backend protocol improvements proposal
(request).
Hackers,
While developing a C++ client library for Postgres I felt lack
Hackers,
While developing a C++ client library for Postgres I felt lack of extra
information in command tags in the CommandComplete (B) message
for the following commands:
PREPARE;
DEALLOCATE;
DECLARE;
CLOSE;
LISTEN;
UNLISTEN;
SET;
RESET.
Namely, for example, users of my library
2013/6/8 Giovanni Mascellani g.mascell...@gmail.com
Hi.
Il 05/06/2013 22:52, Dmitriy Igrishin ha scritto:
At the moment libpq doesn't seem to support asynchronous and
non-blocking support for large objects, in the style of
PQsendQuery/PQgetResult. This makes large objects hardly suited
2013/6/6 Tatsuo Ishii is...@postgresql.org
Hi.
At the moment libpq doesn't seem to support asynchronous and
non-blocking support for large objects, in the style of
PQsendQuery/PQgetResult. This makes large objects hardly suited for
single-threaded programs based on some variant of
According to http://www.postgresql.org/docs/9.2/static/libpq-async.html
Even when PQresultStatus indicates a fatal error, PQgetResult should be
called
until it returns a null pointer, to allow libpq to process the error
information completely.
In libpq/fe-exec.c:PQexecFinish() error messages
2013/6/5 Giovanni Mascellani g.mascell...@gmail.com
Hi.
At the moment libpq doesn't seem to support asynchronous and
non-blocking support for large objects, in the style of
PQsendQuery/PQgetResult. This makes large objects hardly suited for
single-threaded programs based on some variant of
2013/4/21 Bruce Momjian br...@momjian.us
I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2. Those dates might change,
but that is the current plan. I have completed a draft 9.3 release
notes, which you can view here:
2013/1/2 Heikki Linnakangas hlinnakan...@vmware.com
On 02.01.2013 17:27, Marko Kreen wrote:
On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltanz...@cybertec.at
wrote:
2012-12-11 16:09 keltezéssel, Simon Riggs írta:
On 11 December 2012 12:18, Boszormenyi Zoltanz...@cybertec.at wrote:
2012/9/12 Peter Eisentraut pete...@gmx.net
I was surprised to find that psql -f file.sql with a file such as this
select 1;
select 2
executes both commands even though the second one is not terminated.
I realize that this is inconsistently handled throughout the system, for
example libpq
Hey Jim,
2012/8/8 Jim Vanns james.va...@framestore.com
Hello PG hackers. Yesterday I began diagnosing a peculiar bug in some
production code that has been happily running for months. I finally got
to the bottom of it despite the rather misleading error message. Anyway,
within a section of
Hey all,
Could you tell me please an objective reason why PQunescapeBytea()
returns unsigned char* rather than just char* ?
I am asking because a bit confused. How this intermixes with LO's API,
which based on signed chars (although as we all know large object -
is a just bytea splitted on
Hey Alexander,
2011/11/24 Alexander Shulgin a...@commandprompt.com
Excerpts from Florian Weimer's message of Wed Nov 23 13:04:47 +0200 2011:
* Alexander Shulgin:
This, in my opinion, is very similar to what we would like to achieve
with the URI syntax, so the above could also be
2011/11/24 Alexander Shulgin a...@commandprompt.com
Excerpts from Dmitriy Igrishin's message of Thu Nov 24 09:19:02 +0200 2011:
If host part of the URI points to localhost, the UNIX domain socket
would
be considered by libpq just as if you would pass -h localhost -p
5433.
But
2011/6/23 Merlin Moncure mmonc...@gmail.com
On Jun 6 (
http://archives.postgresql.org/pgsql-hackers/2011-06/msg00272.php),
Pavel discovered an issue with PQsetvalue that could cause libpq to
wander off into unallocated memory that was present in 9.0.x. A
fairly uninteresting fix was quickly
2011/6/23 Andrew Chernow a...@esilo.com
you are creating as you iterate through. This behavior was
unnecessary in terms of what libpqtypes and friends needed and may (as
Tom suggested) come back to bite us at some point. As it turns out,
PQsetvalue's operation on results that
Hey Jeff,
2011/6/19 Jeff Shanab jsha...@smartwire.com
I am wondering If I am missing something obvious. If not, I have a
suggestion for plpgsql.
** **
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
** **
Wouldn’t it be a great interface if PQResult
Hey all,
Oleg Bartunov and I intend to begin the project of translation
of PostgreSQL documentation on Russian.
First of all, we want to create glossary to be used by translators.
However we consider that it would be nice to generalize this idea
and create a multi-language glossary of PostgreSQL
2011/1/12 Robert Haas robertmh...@gmail.com
On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian br...@momjian.us wrote:
The attached patch is a collection of libpq documentation cleanups
recommended in a list of changes emailed to me by Leslie S Satenstein.
Leslie found a number of places
2010/12/17 Merlin Moncure mmonc...@gmail.com
On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/12/17 Tom Lane t...@sss.pgh.pa.us:
Furthermore, it's underspecified: who's to say how many dimensions of
the array are
Magnus, thats great ! And name PQlibVersion is correct ! Thanks.
2010/12/16 Magnus Hagander mag...@hagander.net
On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin c...@ghum.de wrote:
My question: Which way is available to query the linked libpq version?
But it does outline that fact that
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 02:14 , James William Pye wrote:
On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
how do you identify which type OID is really hstore?
How about an identification field on pg_type?
CREATE TYPE hstore ..., IDENTIFIER
2010/12/15 Jan Urbański wulc...@wulczer.org
On 15/12/10 16:11, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I was asking what would satisfy you as regards a reliable way to
identify a type, not what you think we should do about this particular
proposal.
Okay: a
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 02:14 , James William Pye wrote:
On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
how do you identify which type OID is really hstore
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 02:14 , James William Pye wrote:
On Dec 13
2010/12/15 Pavel Stehule pavel.steh...@gmail.com
2010/12/15 Dmitriy Igrishin dmit...@gmail.com:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote
2010/12/15 Dmitriy Igrishin dmit...@gmail.com
2010/12/15 Robert Haas robertmh...@gmail.com
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas robertmh...@gmail.com
wrote:
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Yes, but range of PostgreSQL's OIDs can
2010/12/15 Dmitriy Igrishin dmit...@gmail.com
2010/12/15 Pavel Stehule pavel.steh...@gmail.com
2010/12/15 Dmitriy Igrishin dmit...@gmail.com:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
2010/12/16 Florian Pflug f...@phlo.org
On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote:
Florian Pflug f...@phlo.org writes:
Not if CREATE EXTENSION allows you install hstore into an arbitrary
schema.
It also allows you to change it after the fact, and to easily track it
down. Here's
2010/12/15 Robert Haas robertmh...@gmail.com
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas robertmh...@gmail.com
wrote:
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
millions, e.g. can
2010/12/14 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/14 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin
Hey Pavel,
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
Hello
this is little bit offtopic, sorry.
I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.
Could you tell
/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
Hey Pavel,
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
Hello
this is little bit offtopic, sorry.
I am thinking, so we need a standard associative array support in core
- like Perl
There are a lot of operators and functions to work with hstore.
Does it worth it to implement similar things only to make it
possible using operator [] ?
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
name and interface - hstore is designed as external module - a
internal class can be
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
There are a lot of operators and functions to work with hstore.
Does it worth it to implement similar things only to make it
possible using operator [] ?
yes
2010/12/13 Pavel Stehule
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
There are a lot of operators and functions to work with hstore.
Does it worth
2010/12/14 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin dmit...@gmail.com:
2010/12/13 Pavel Stehule pavel.steh...@gmail.com
2010/12/13 Dmitriy Igrishin
Hey Pavel,
Everything looks fine, but I propose you to add record_set_field
just for convenience and as opposite of record_get_field.
2010/12/11 Pavel Stehule pavel.steh...@gmail.com
Hello
I wrote a few functions for record type - record_expand,
record_get_fields, record_get_field,
Hey Robert,
2010/12/10 Robert Haas robertmh...@gmail.com
On Fri, Dec 10, 2010 at 2:53 AM, Dmitriy Igrishin dmit...@gmail.com
wrote:
[ message that was forwarded to three mailing lists in an 12 hour period
]
Come on, give me a break!
Please sorry ! But I don't mail to you personally
Hey Kevin,
Oh, I am sorry! Thanks!
2010/12/10 Kevin Grittner kevin.gritt...@wicourts.gov
Dmitriy Igrishin wrote:
Where is it written ?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do
-Kevin
--
// Dmitriy.
2010/12/10 Robert Haas robertmh...@gmail.com
On Fri, Dec 10, 2010 at 11:46 AM, Dmitriy Igrishin dmit...@gmail.com
wrote:
It would be quicker to answer my question and help than to teach me
the alphabet of communication. Although, thank you, and for that :-)
It would be quicker still
-- Forwarded message --
From: Dmitriy Igrishin dmit...@gmail.com
Date: 2010/12/10
Subject: Fwd: Extended query protocol and exact types matches.
To: postgres list pgsql-...@postgresql.org
Hey sql@,
-- Forwarded message --
From: Dmitriy Igrishin dmit...@gmail.com
Hey Florian,
Thank you very much!
2010/12/8 Florian Pflug f...@phlo.org
On Dec8, 2010, at 11:35 , Dmitriy Igrishin wrote:
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore or this convention
can be changed in future ?
What's
Hey Andrew,
Finally convinced. Thanks!
2010/12/8 Andrew Dunstan and...@dunslane.net
On 12/08/2010 05:35 AM, Dmitriy Igrishin wrote:
Hey hackers@,
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore or this convention
can be changed
Hey Tom,
Thanks you too.
I always read the documentation, but don't want (yes, don't want)
to read a lot of code to get the answer on simple question because
life is too short for it. I think that people should helps each other :-)
2010/12/8 Tom Lane t...@sss.pgh.pa.us
Dmitriy Igrishin dmit
. Respect! :-)
2010/12/8 Robert Haas robertmh...@gmail.com
On Wed, Dec 8, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dmitriy Igrishin dmit...@gmail.com writes:
I always read the documentation, but don't want (yes, don't want)
to read a lot of code to get the answer on simple question
Hey Merlin,
Do you mean that due to binary transfer it is possible
to determine the type of data transfered to the backend
and therefore there is no need to pass OIDs ?
2010/12/7 Merlin Moncure mmonc...@gmail.com
On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan and...@dunslane.net
wrote:
On
Hey hackers@,
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore or this convention
can be changed in future ?
Thanks.
--
// Dmitriy.
Hey hackers@,
libpq execution function works with OIDs. In some cases it is
highly recommended specify OIDs of parameters according to
libpq documentation.
While developing a database application with libpq and if
application works with custom data types IMO reasonable to
provide developer
The reasons are simple, particularly, I don't want to bloat SQL
with CAST or ::. Its not elegant and looks ugly. If I need to bind
e.g. int or short I don't want write ::integer or ::smallint in SQL,
because I can easily map int to integer via OID...
I don't clearly understand how
IMO, it would be better to implement some utility functions to
make it easy to construct arrays dynamically for PQexecParams
and PQexecPrepared. This seems to me more universal solution
and it is useful for both -- high level libpq-libraries authors and for
those who like to use libpq directly.
2010/12/6 Andrew Chernow a...@esilo.com
On 12/6/2010 11:40 AM, Dmitriy Igrishin wrote:
IMO, it would be better to implement some utility functions to
make it easy to construct arrays dynamically for PQexecParams
and PQexecPrepared. This seems to me more universal solution
and it is useful
Hey hackers,
Varargs-exec is useful only when programmer calls it directly.
It is useless when libpq is used to create a more flexible high-level
library (e.g., for C++). PQexecParams (PQexecPrepared) are good
for it.
What about auto reconnect. There are PQreset already and
PG_CONNECTION_OK
Hey Andrew,
No, thanks. :-)
And I don't think that libpq should follows it (libpqtypes).
2010/12/6 Andrew Chernow a...@esilo.com
A varargs version of PQexecParams() would be handy, though. Imagine being
able
to do:
PQexecVParams(SELECT * FROM mytable WHERE foo = $1 AND bar = $2, foovar,
Hey,
I don't clearly understand why anybody should perform DELETE
directly from a psql terminal on a production system. WHY ?
I can't understand what problem with DELETE without WHERE clause
for application developers and why DBMS should protect them
from DELETE FROM table.
PS. Anybody can
Hey Dimitri, hackers,
Okay, there is a some getddl utility. But as for me, it does not
simplify the development. It is file-based pgAdmin with the
exception that I can use, e.g. Emacs for editing rather than
build-in editor of pgAdmin. But I can use Emacs from psql(1)...
Without some restoreddl
Hey hackers,
I am sorry, but is it possible to implement BTW ability to
check exactly status of authentication from libpq ? As for now,
the only way to check failed authentication is parsing the error
message, that is sadly.
2010/11/26 Bruce Momjian br...@momjian.us
Fujii Masao wrote:
On
Hey hackers,
Completely agree with Robert !
It would be nice to dump functions definitions, e.g. to make it possible
keep them in git separately.
I also want to propose to make it possible dump function definitions
as CREATE OR REPLACE FUNCTION rather than just CREATE
FUNCTION (as pg_dump dumps
Hey Pavel,
2010/11/9 Pavel Stehule pavel.steh...@gmail.com
a) transformation to common type
+ simple - it is one day job - function record_to_array,
array_to_record, and fieldnames_to_array
- lost of type info, hidden problems with IO cast - int a := 10.0/2.0
is a problem
using
Hey David,
2010/11/9 David E. Wheeler da...@kineticode.com
On Nov 9, 2010, at 1:38 AM, Dmitriy Igrishin wrote:
* text[] = record_to_array(record)
* table(id, key, datatype, value) = record_to_table(record)
* text = record_get_field(record, text)
* record = record_set_field(record, text
Hey Pavel, Tom, Merlin,
As a user, I would like to work with records by using simple API:
-- Returns a number of key/values pairs of record.
nKeys_ integer := nRecordKeys(NEW);
-- Returns an i-th key.
key_i text := recordKey(NEW, i);
-- Returns an i-th value.
value1_ text :=
, 2010 at 3:02 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Hey Pavel, Tom, Merlin,
As a user, I would like to work with records by using simple API:
-- Returns a number of key/values pairs of record.
nKeys_ integer := nRecordKeys(NEW);
-- Returns an i-th key.
key_i text
Hey Robert,
I've asked pgsql-general.
Unfortunately it seems that there is no better way to do it except
parsing PQerrorMessage(). Sadly.
2010/10/17 Robert Haas robertmh...@gmail.com
On Thu, Oct 14, 2010 at 2:59 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Is there way to determine failed
Hey all,
Is there way to determine failed connection attempt due to invalid
authorization (libpq)?
--
// Dmitriy.
Hey Robert, Tom
Tom, thank you for explanation!
Ouch. Letting people write data to where they can't get it back from
seems double-plus ungood.
Robert, yes, I agree with you. This is exactly what I wanted to say.
I've implemented a stream class in C++ and this circumstance makes
the code not
Hey Robert,
Yes, I am sure. I've tested it by test case in my original post.
Do you can compile and reproduce it please?
--
// Dmitriy.
Hey all,
Here is simple test case of LOB usage, please, note the comments:
#include libpq-fe.h
#include libpq/libpq-fs.h
int main(int argc, char* argv[])
{
PGconn* c = PQconnectdb(password=test);
PGresult* r = PQexec(c, BEGIN);
PQclear(r);
const unsigned int id = lo_create(c, 0);
Hey all,
Okay, as Robert points, 0 code in successful messages seems as waste
of bytes. But according to the documentation, All messages emitted by the
PostgreSQL server are assigned five-character error codes that follow the
SQL
standard's conventions for SQLSTATE codes. - the first sentence
Hey all,
Accordingly to the documentation of libpq, SQLSTATE code field is not
localizable, and
is always present.. But it seems, in some cases it isn't. E.g.
/* the main code */
PGresult* res = Pg::PQexec(conn, select 1);
Oid id = PQparamtype(res, 1);
/* the notice receiver */
void
Hey all,
According to
http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
some error conditions has non-unique *names*. There are:
modifying_sql_data_not_permitted,
prohibited_sql_statement_attempted,
reading_sql_data_not_permitted
from SQL Routine Exception and External Routine
Thanks for you answer, Tom!
I've implemented mapping between SQLSTATE codes and C++ exception
classes of my library. And of course, I've resolved the conflict of names
by giving a proper name to my classes.
Regards,
Dmitriy
2010/8/16 Tom Lane t...@sss.pgh.pa.us
Dmitriy Igrishin dmit
Hey all,
Is it guaranteed that functions, which accept PGconn* (PGresult*)
properly works if PGconn* (PGresult*) is NULL or is it better to check
on NULL the value of the pointer before calling those functions?
Regards,
Dmitriy
Hey all,
It seams, that all of the error codes should be obtained by calling
PQresultErrorField().
But this function works only with results. So in what situations
TOO MANY CONNECTIONS error may be thrown after successfully connection ? :)
In case of dblink?
Regards,
Dmitriy
76 matches
Mail list logo
