2014-09-22 12:36 GMT+04:00 Marko Tiikkaja :
> On 9/22/14 9:45 AM, Dmitriy Igrishin wrote:
>
>> 2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
>>
>> On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
>>> wrote:
>>>
>>>> Why are you using c
2014-09-22 11:35 GMT+04:00 Daniele Varrazzo :
> On Mon, Sep 22, 2014 at 8:17 AM, Dmitriy Igrishin
> wrote:
> >
> > 2014-09-22 10:42 GMT+04:00 Daniele Varrazzo >:
>
> >> [2] https://gist.github.com/dvarrazzo/065f343c95f8ea67cf8f
> >
> >
2014-09-22 10:42 GMT+04:00 Daniele Varrazzo :
> 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 don't know if the two c
2013/7/9 Merlin Moncure
> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou 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 usually write in C,
> > so t
2013/6/21 Albe Laurenz
> 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
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 ca
2013/6/8 Giovanni Mascellani
> 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. T
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 merg
2013/6/6 Tatsuo Ishii
> > 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 select().
>
2013/6/5 Giovanni Mascellani
> 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 select().
>
Accor
2013/4/21 Bruce Momjian
> 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:
>
> http://momjian
2013/1/2 Heikki Linnakangas
> On 02.01.2013 17:27, Marko Kreen wrote:
>
>> On Wed, Jan 2, 2013 at 5:11 PM, Boszormenyi Zoltan
>> wrote:
>>
>>> 2012-12-11 16:09 keltezéssel, Simon Riggs írta:
>>>
>>> On 11 December 2012 12:18, Boszormenyi Zoltan wrote:
Such mechanism already exist -
2012/9/12 Peter Eisentraut
> 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 APIs d
Hey Jim,
2012/8/8 Jim Vanns
> 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 code we are making a DELE
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 chunks)
2011/11/24 Alexander Shulgin
>
> 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 what if
Hey Alexander,
2011/11/24 Alexander Shulgin
>
> 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 specified using
2011/6/23 Andrew Chernow
> 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 weren't cr
2011/6/23 Merlin Moncure
> 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 produced, but
Hey Jeff,
2011/6/19 Jeff Shanab
> 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 was “bi-di
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 t
2011/1/12 Robert Haas
> On Wed, Jan 12, 2011 at 11:53 AM, Bruce Momjian 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 our libpq documentation that we
2010/12/17 Merlin Moncure
> On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane wrote:
> > Pavel Stehule writes:
> >> 2010/12/17 Tom Lane :
> >>> Furthermore, it's underspecified: who's to say how many dimensions of
> >>> the array are supposed to get sliced off? There's no reasonable place
> >>> to ex
Magnus, thats great ! And name PQlibVersion is correct ! Thanks.
2010/12/16 Magnus Hagander
> On Tue, Dec 14, 2010 at 17:56, Massa, Harald Armin wrote:
> >>> My question: Which way is available to query the linked libpq version?
> >
> >> But it does outline that fact that it wouldn't suck to ha
2010/12/15 Robert Haas
> On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas
> wrote:
> > On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin
> wrote:
> >> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
> >> millions, e.g. can be enough.
2010/12/16 Florian Pflug
> On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote:
> > Florian Pflug 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 an updated ve
2010/12/15 Dmitriy Igrishin
>
>
> 2010/12/15 Pavel Stehule
>
> 2010/12/15 Dmitriy Igrishin :
>> >
>> >
>> > 2010/12/15 Florian Pflug
>> >>
>> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
>> >> > 20
2010/12/15 Dmitriy Igrishin
>
>
> 2010/12/15 Robert Haas
>
> On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas
>> wrote:
>> > On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin
>> wrote:
>> >> Yes, but range of PostgreSQL's OIDs can be reserve
2010/12/15 Pavel Stehule
> 2010/12/15 Dmitriy Igrishin :
> >
> >
> > 2010/12/15 Florian Pflug
> >>
> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
> >> > 2010/12/15 Florian Pflug
> >> > On Dec15, 2010, at 16:18 , Dmitriy I
2010/12/15 Florian Pflug
> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
> > 2010/12/15 Florian Pflug
> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
> > >> 2010/12/15 Florian Pflug
> > >> On Dec15, 2010, at 02:14 , James William Pye wrote:
&g
2010/12/15 Florian Pflug
> On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
> >> 2010/12/15 Florian Pflug
> >> 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 wh
2010/12/15 Jan Urbański
> On 15/12/10 16:11, Tom Lane wrote:
> > Robert Haas 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 preassigned OID is safe. I haven'
2010/12/15 Florian Pflug
> 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 'org.postgresq
2010/12/14 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/14 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> >
> >> >
> >> > 2010/12/13 Pavel Stehule
> >> >>
&g
2010/12/14 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> >
> >> >
> >> > 2010/12/13 Pavel Stehule
> >> >>
> >>
2010/12/13 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> >
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> 2010/12/13 Dmitriy Igrishin :
> >> > There are a lot of operators and functions to work with hstore.
> >> > Does it worth it to
2010/12/13 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> > 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 Pa
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
> >>
> >> name and interface - hstore is designed as external module - a
> >> internal class can be designed differen
/13 Pavel Stehule
> 2010/12/13 Dmitriy Igrishin :
> > Hey Pavel,
> >
> > 2010/12/13 Pavel Stehule
> >>
> >> Hello
> >>
> >> this is little bit offtopic, sorry.
> >>
> >> I am thinking, so we need a standard associative arra
Hey Pavel,
2010/12/13 Pavel Stehule
> 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 why in-core assoc
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
> Hello
>
> I wrote a few functions for record type - record_expand,
> record_get_fields, record_get_field, record_set_fields.
>
> A usa
2010/12/10 Robert Haas
> On Fri, Dec 10, 2010 at 11:46 AM, Dmitriy Igrishin
> 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 to igno
Hey Kevin,
Oh, I am sorry! Thanks!
2010/12/10 Kevin Grittner
> Dmitriy Igrishin wrote:
>
> > Where is it written ?
>
>
> http://wiki.postgresql.org/wiki/Guide_to_reporting_problems#Things_Not_To_Do
>
> -Kevin
>
>
--
// Dmitriy.
Hey Robert,
2010/12/10 Robert Haas
> On Fri, Dec 10, 2010 at 2:53 AM, Dmitriy Igrishin
> 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.
&g
-- Forwarded message --
From: Dmitriy Igrishin
Date: 2010/12/10
Subject: Fwd: Extended query protocol and exact types matches.
To: postgres list
Hey sql@,
-- Forwarded message --
From: Dmitriy Igrishin
Date: 2010/12/9
Subject: Extended query protocol and
ithout pointing me to the sources. Respect! :-)
2010/12/8 Robert Haas
> On Wed, Dec 8, 2010 at 11:09 AM, Tom Lane wrote:
> > Dmitriy Igrishin writes:
> >> I always read the documentation, but don't want (yes, don't want)
> >> to read a lot of code to get the answ
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
> Dmitriy Igrishin writ
Hey Andrew,
Finally convinced. Thanks!
2010/12/8 Andrew Dunstan
>
>
> 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
Hey Florian,
Thank you very much!
2010/12/8 Florian Pflug
> 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 fu
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.
2 AM, Merlin Moncure wrote:
> >> On Tue, Dec 7, 2010 at 9:10 AM, Dmitriy Igrishin
> >> wrote:
> >>>
> >>> Hey hackers@,
> >>>
> >>> libpq execution function works with OIDs. In some cases it is
> >>> highly recommended s
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 set_next_pg_type_
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 extende
2010/12/6 Andrew Chernow
> 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
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.
20
Hey Andrew,
No, thanks. :-)
And I don't think that libpq should follows it (libpqtypes).
2010/12/6 Andrew Chernow
>
> 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 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 (_BAD
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 perf
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
> Fujii Masao wrote:
> > On Fri, Nov 26, 2010
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 "restoredd
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 th
Hey David,
2010/11/9 David E. Wheeler
> 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 =
Hey Pavel,
2010/11/9 Pavel Stehule
> > 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 a plperl
10 at 3:02 PM, Dmitriy Igrishin
> 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);
> >
>
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 := recordV
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
> On Thu, Oct 14, 2010 at 2:59 PM, Dmitriy Igrishin
> wrote:
> > Is there way to determine failed connection attem
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 no
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
#include
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);
int fd1 = lo_open(c, id,
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 sen
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 */
voi
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
> Dmitriy Igrishin writes:
>
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 Excep
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
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
76 matches
Mail list logo
