On Sun, Apr 3, 2016, 18:32 Tom Lane wrote:
> Peter Geoghegan writes:
> > On Thu, Feb 11, 2016 at 9:50 AM, Robert Haas
> wrote:
> >> Wow, that's a fabulous idea. I see Oleksandr has tried to implement
> >> it, although I haven't looked at the patch. But I think this would be
> >> REALLY helpfu
Peter Geoghegan writes:
> On Thu, Feb 11, 2016 at 9:50 AM, Robert Haas wrote:
>> Wow, that's a fabulous idea. I see Oleksandr has tried to implement
>> it, although I haven't looked at the patch. But I think this would be
>> REALLY helpful.
> +1
Pushed.
regards, tom l
Alex Shulgin writes:
> What about regression tests? My assumption was that we won't be able to
> add them with the usual expected file approach, but that we also don't need
> it that hard. Everyone's in favor?
It'd be nice to have a regression test, but I concur that the LOCATION
information is
On Sat, Apr 2, 2016 at 11:41 PM, Tom Lane wrote:
> "Shulgin, Oleksandr" writes:
> > On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote:
> >> Yeah, I don't much like that either. But I don't think we can avoid
> >> some refactoring there; as designed, conversion of an error message into
> >> user-
On Thu, Feb 11, 2016 at 9:50 AM, Robert Haas wrote:
>> Actually, what'd be really handy IMO is something to regurgitate the
>> most recent error in verbose mode, without making a permanent session
>> state change. Something like
>>
>> regression=# insert into bar values(1);
>> ERROR: insert or u
I wrote:
> Attached is a libpq-portion-only version of a patch doing it this way.
> I've not yet looked at the psql part of your patch.
Here's an update for the psql side.
regards, tom lane
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index
"Shulgin, Oleksandr" writes:
> On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote:
>> Yeah, I don't much like that either. But I don't think we can avoid
>> some refactoring there; as designed, conversion of an error message into
>> user-visible form is too tightly tied to receipt of the message.
On Tue, Mar 15, 2016 at 4:44 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
> On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote:
>
>> "Shulgin, Oleksandr" writes:
>> > What I dislike about this POC is all the disruption in libpq, to be
>> > honest.
>>
>> Yeah, I don't much like that
On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote:
> "Shulgin, Oleksandr" writes:
> > What I dislike about this POC is all the disruption in libpq, to be
> > honest.
>
> Yeah, I don't much like that either. But I don't think we can avoid
> some refactoring there; as designed, conversion of an err
"Shulgin, Oleksandr" writes:
> What I dislike about this POC is all the disruption in libpq, to be
> honest.
Yeah, I don't much like that either. But I don't think we can avoid
some refactoring there; as designed, conversion of an error message into
user-visible form is too tightly tied to recei
On Wed, Feb 10, 2016 at 12:33 AM, Daniel Verite
wrote:
> Shulgin, Oleksandr wrote:
>
> > Most importantly, I'd like to learn of better options than storing the
> > whole last_result in psql's pset structure.
>
> I guess that you could, each time a query fails, gather silently the
> result
On Thu, Feb 11, 2016 at 10:53 AM, Pavel Stehule
wrote:
> > most recent error in verbose mode, without making a permanent session
>
>> > state change. Something like
>> >
>> > regression=# insert into bar values(1);
>> > ERROR: insert or update on table "bar" violates foreign key constraint
>> "
> most recent error in verbose mode, without making a permanent session
> > state change. Something like
> >
> > regression=# insert into bar values(1);
> > ERROR: insert or update on table "bar" violates foreign key constraint
> "bar_f1_fkey"
> > DETAIL: Key (f1)=(1) is not present in table "f
On Tue, Jan 5, 2016 at 10:16 PM, Tom Lane wrote:
> Jim Nasby writes:
>> FWIW, I suspect very few people know about the verbosity setting (I
>> didn't until a few months ago...) Maybe psql should hint about it the
>> first time an error is reported in a session.
>
> Actually, what'd be really hand
Shulgin, Oleksandr wrote:
> Most importantly, I'd like to learn of better options than storing the
> whole last_result in psql's pset structure.
I guess that you could, each time a query fails, gather silently the
result of \errverbose, store it in a buffer, discard the PGresult,
and in c
On Mon, Feb 8, 2016 at 5:24 PM, Daniel Verite
wrote:
> Shulgin, Oleksandr wrote:
>
> > Added to the Open commitfest: https://commitfest.postgresql.org/9/475/
>
> Here's a review. Note that the patch tested and submitted
> is not the initial one in the thread, so it doesn't exactly
> match
Shulgin, Oleksandr wrote:
> Added to the Open commitfest: https://commitfest.postgresql.org/9/475/
Here's a review. Note that the patch tested and submitted
is not the initial one in the thread, so it doesn't exactly
match $subject now.
What's tested here is a client-side approach, sugge
On Wed, Jan 6, 2016 at 3:02 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
>
> Please find attached a POC patch, using \errverbose for the command name.
> Unfortunately, I didn't see a good way to contain the change in psql only
> and had to change libpq, adding new interface PQresu
On Wed, Jan 6, 2016 at 5:06 AM, Jim Nasby wrote:
> On 1/5/16 9:16 PM, Tom Lane wrote:
>
>> Jim Nasby writes:
>>
>>> FWIW, I suspect very few people know about the verbosity setting (I
>>> didn't until a few months ago...) Maybe psql should hint about it the
>>> first time an error is reported in
On 1/5/16 9:16 PM, Tom Lane wrote:
Jim Nasby writes:
FWIW, I suspect very few people know about the verbosity setting (I
didn't until a few months ago...) Maybe psql should hint about it the
first time an error is reported in a session.
Actually, what'd be really handy IMO is something to reg
Jim Nasby writes:
> FWIW, I suspect very few people know about the verbosity setting (I
> didn't until a few months ago...) Maybe psql should hint about it the
> first time an error is reported in a session.
Actually, what'd be really handy IMO is something to regurgitate the
most recent error
On 1/5/16 8:41 PM, Tom Lane wrote:
Jim Nasby writes:
>does psql do anything with those fields? ISTM the biggest use for this
>info is someone sitting at psql or pgAdmin.
Sure, if you turn up the error verbosity.
FWIW, I suspect very few people know about the verbosity setting (I
didn't unti
Jim Nasby writes:
> does psql do anything with those fields? ISTM the biggest use for this
> info is someone sitting at psql or pgAdmin.
Sure, if you turn up the error verbosity.
regression=# create table foo (f1 int primary key);
CREATE TABLE
regression=# create table bar (f1 int references fo
On 1/5/16 7:21 PM, Tom Lane wrote:
What seems more likely to be useful and to not break anything is to push
forward on adding PG_DIAG_SCHEMA_NAME and similar auxiliary fields to more
error messages (see errtable() and siblings). That would allow
applications to extract this information automatic
Petr Korobeinikov writes:
> At the moment schemas used as single-level namespaces.
> It's quite convenient in large databases.
> But error messages doesnât contain schema names.
> I have done a little patch with schema-qualified relation names in error
> messages that produced by foreign key c
Hackers,
At the moment schemas used as single-level namespaces.
It's quite convenient in large databases.
But error messages doesn’t contain schema names.
I have done a little patch with schema-qualified relation names in error
messages that produced by foreign key constraints and triggers.
Pat
26 matches
Mail list logo