Re: [pgadmin-hackers] pgAdmin III commit: Lots of work on domains, and check constraints

2012-09-05 Thread Dave Page
On Tue, Sep 4, 2012 at 10:05 PM, Guillaume Lelarge
 wrote:
> On Mon, 2012-09-03 at 22:41 +0200, Guillaume Lelarge wrote:
>> On Mon, 2012-09-03 at 08:54 +0100, Dave Page wrote:
>> > On Fri, Aug 31, 2012 at 10:57 PM, Guillaume Lelarge
>> >  wrote:
>> > > On Sun, 2012-08-26 at 18:18 +0200, Guillaume Lelarge wrote:
>> > >> On Mon, 2012-07-23 at 08:38 +0100, Dave Page wrote:
>> > >> > On Sat, Jul 21, 2012 at 1:40 PM, Guillaume Lelarge
>> > >> >  wrote:
>> > >> > > On Wed, 2012-06-06 at 10:50 +0600, Timon wrote:
>> > >> > >> seems that this commit broke reindexing of selected index. steps 
>> > >> > >> to reproduce:
>> > >> > >> 1) create table
>> > >> > >> 2) create index
>> > >> > >> 3) select index in object inspector
>> > >> > >> 4) try to reindex it via maintenance menu item
>> > >> > >> 5) got error : ERROR:  schema "table_name" does not exist
>> > >> > >>
>> > >> > >> and one more crash here
>> > >> > >> .. same steps as before
>> > >> > >> 4) try to CLUSTER index
>> > >> > >> 5) pgadmin simply crashed
>> > >> > >>
>> > >> > >
>> > >> > > OK, I finally got some time to work on this. As Timon said, these 
>> > >> > > bugs
>> > >> > > come from the patch "Lots of work on domains, and check 
>> > >> > > constraints". In
>> > >> > > this patch, I changed some objects parent class from pgTableObject 
>> > >> > > to
>> > >> > > pgSchemaObject. Due to this change, the GetTable() method returns 
>> > >> > > NULL,
>> > >> > > which segfaults all statements that try to use the return value 
>> > >> > > without
>> > >> > > checking. The two examples above from Timon are exactly this.
>> > >> > >
>> > >> > > I don't see many ways to get out of this issue.
>> > >> > >
>> > >> > > We could use GetSchema() instead of GetTable(). It works, it's an 
>> > >> > > easy
>> > >> > > and small patch. But it'll certainly be a maintenance nightmare (at
>> > >> > > least without any comments)
>> > >> > >
>> > >> > > We could also revert my patch. It's simple, we loose the feature of
>> > >> > > adding as many check constraints as we want to a domain, we loose 
>> > >> > > the
>> > >> > > feature of renaming and validating constraints, and we gain a few 
>> > >> > > bugs.
>> > >> > >
>> > >> > > I don't see any other options. My own personal choice would be the 
>> > >> > > first
>> > >> > > one (see attached patch). But it's a tough call.
>> > >> >
>> > >> > We've run into problems in the past every time we've tried to share a
>> > >> > sub-class between two parents. I think we should stop trying to do
>> > >> > that, and just resign ourselves to having to duplicate the class - I
>> > >> > guess pgCheckConstraint and pgDomainCheckConstraint is the way to go.
>> > >>
>> > >> I don't think I'll have the time and motivation to work on this before
>> > >> we go GA. I guess I'll have to do this later on but in the mean time,
>> > >> should I revert my commit or apply this patch?
>> > >>
>> > >
>> > > Dave, any comment?
>> >
>> > What does the patch look like? As long as it's safe, well commented,
>> > and overall the new code is an improvement, it seems like it's the
>> > best option.
>> >
>>
>> I'll work on it tomorrow. If it sounds good enough to me, I'll apply it.
>> Otherwise, I'll revert my old patch.
>>
>
> Done. I cannot say that it will fix all issues, but at least it fixes
> the one I know. There's still an issue found by Erwin, that I can't be
> sure because the trac website is still down.

Sorry - for some reason when you reported this before I got it into my
head that you meant redmine.postgresql.org. Trac is fixed now.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


[pgadmin-hackers] pgAdmin III commit: Fix quoting of function identifiers.

2012-09-05 Thread Dave Page
Fix quoting of function identifiers.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=27bc5c09f4ae25f1ab449167efddd098218532fe

Modified Files
--
pgadmin/dlg/dlgFunction.cpp |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


[pgadmin-hackers] pgAdmin III commit: Fix quoting of function identifiers.

2012-09-05 Thread Dave Page
Fix quoting of function identifiers.

Branch
--
REL-1_16_0_PATCHES

Details
---
http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=2096d22d800eb30a3b22eed023bd2e061daa54fe

Modified Files
--
pgadmin/dlg/dlgFunction.cpp |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] Unable to create new function if "Owner" or "Comment" is specified.

2012-09-05 Thread Dave Page
Hi

On Tue, Sep 4, 2012 at 6:14 PM, Sachin Srivastava
 wrote:
>
> Hi,
>
> Due to re-quoting of already quoted schema qualified function name in the
> "ALTER FUNCTION  OWNER to " query while adding a
> new function we get an error about function name not found.
>
> Attached is a patch that fixes the issue.

Thanks - unfortunately that's still not right, as it duplicates the
schema name when creating new functions. I've applied the patch below
which seems to work in both the create and edit cases:

diff --git a/pgadmin/dlg/dlgFunction.cpp b/pgadmin/dlg/dlgFunction.cpp
index d102b97..1d2cc1c 100644
--- a/pgadmin/dlg/dlgFunction.cpp
+++ b/pgadmin/dlg/dlgFunction.cpp
@@ -975,16 +975,19 @@ wxString dlgFunction::GetSql()
}
}

-   name = schema->GetQuotedPrefix() + qtIdent(name)
-  + wxT("(") + GetArgs(false, true) + wxT(")");

if (function)
{
+   name = schema->GetQuotedPrefix() + qtIdent(name)
+   + wxT("(") + GetArgs(false, true) + wxT(")");
+
AppendOwnerChange(sql, wxT("FUNCTION ") + name);
AppendSchemaChange(sql, wxT("FUNCTION ") + name);
}
else
{
+   name = name + wxT("(") + GetArgs(false, true) + wxT(")");
+
if (cbOwner->GetCurrentSelection() > 0)
AppendOwnerNew(sql, wxT("FUNCTION ") + name);
}


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


[pgadmin-hackers] pldebugger blank code issue

2012-09-05 Thread Jon Garate
Hello dear list,

I'm having trouble after setting up pldebugger git-current
(eb754b6ba9a1c18e7bc4ddf521408be06768c697) commit in a Ubuntu 10.04.01
x86_64 box. Server versión is 9.1.5.
The issue is that once I start debugging a PLPgSQL function within pgAdmin,
once it goes one level down the call stack, the given function's code isn't
shown despite being a proper plpgsql function. You can run it step by step
or continue, and execution is correct (even DBMS messages are displayed in
the bottom pane), but I just can't see the code displayed in the main pane.
If I manually click the original (main) function in the right pane, his
code is shown properly. It seems that certain functions are forbidden from
being shown in the main pane.
I tested this setup with pgAdmin 1.14.0, 1.14.3 and 1.16.0-beta4.
Any idea anyone?

On the side, I see a lot of people having problems these days with 9.1.x
releases. Is current code production-ready?

Thanks in advance,
-- 

Jon Garate


Re: [pgadmin-hackers] pldebugger blank code issue

2012-09-05 Thread Dave Page
On Wed, Sep 5, 2012 at 12:31 PM, Jon Garate  wrote:
> Hello dear list,
>
> I'm having trouble after setting up pldebugger git-current
> (eb754b6ba9a1c18e7bc4ddf521408be06768c697) commit in a Ubuntu 10.04.01
> x86_64 box. Server versión is 9.1.5.
> The issue is that once I start debugging a PLPgSQL function within pgAdmin,
> once it goes one level down the call stack, the given function's code isn't
> shown despite being a proper plpgsql function. You can run it step by step
> or continue, and execution is correct (even DBMS messages are displayed in
> the bottom pane), but I just can't see the code displayed in the main pane.
> If I manually click the original (main) function in the right pane, his code
> is shown properly. It seems that certain functions are forbidden from being
> shown in the main pane.
> I tested this setup with pgAdmin 1.14.0, 1.14.3 and 1.16.0-beta4.
> Any idea anyone?

Use the PRE_9_2 branch with 9.1, not master.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] pldebugger blank code issue

2012-09-05 Thread Jon Garate
I did so before testing master (which build a single .so file). In the case
of the PRE_9_2 branch, I got 3 .so's
When I updated the configuration to load those .so's I got a undefined
symbol error when restarting PostgreSQL. Could it be that I only need to
load a single .so in that case as well?

2012/9/5 Dave Page 

> On Wed, Sep 5, 2012 at 12:31 PM, Jon Garate  wrote:
> > Hello dear list,
> >
> > I'm having trouble after setting up pldebugger git-current
> > (eb754b6ba9a1c18e7bc4ddf521408be06768c697) commit in a Ubuntu 10.04.01
> > x86_64 box. Server versión is 9.1.5.
> > The issue is that once I start debugging a PLPgSQL function within
> pgAdmin,
> > once it goes one level down the call stack, the given function's code
> isn't
> > shown despite being a proper plpgsql function. You can run it step by
> step
> > or continue, and execution is correct (even DBMS messages are displayed
> in
> > the bottom pane), but I just can't see the code displayed in the main
> pane.
> > If I manually click the original (main) function in the right pane, his
> code
> > is shown properly. It seems that certain functions are forbidden from
> being
> > shown in the main pane.
> > I tested this setup with pgAdmin 1.14.0, 1.14.3 and 1.16.0-beta4.
> > Any idea anyone?
>
> Use the PRE_9_2 branch with 9.1, not master.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 

Jon Garate
PROYELIA. Parque tecnológico Miramón. P. Mikeletegi 56. 20009 Donostia-San
Sebastián [mapa ]


Re: [pgadmin-hackers] pldebugger blank code issue

2012-09-05 Thread Dave Page
On Wed, Sep 5, 2012 at 12:45 PM, Jon Garate  wrote:
> I did so before testing master (which build a single .so file). In the case
> of the PRE_9_2 branch, I got 3 .so's
> When I updated the configuration to load those .so's I got a undefined
> symbol error when restarting PostgreSQL. Could it be that I only need to
> load a single .so in that case as well?

Yes. Please see README.pldebugger in the source tree.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] Unable to create new function if "Owner" or "Comment" is specified.

2012-09-05 Thread Sachin Srivastava
On Wed, Sep 5, 2012 at 4:26 PM, Dave Page  wrote:

> Hi
>
> On Tue, Sep 4, 2012 at 6:14 PM, Sachin Srivastava
>  wrote:
> >
> > Hi,
> >
> > Due to re-quoting of already quoted schema qualified function name in the
> > "ALTER FUNCTION  OWNER to " query while
> adding a
> > new function we get an error about function name not found.
> >
> > Attached is a patch that fixes the issue.
>
> Thanks - unfortunately that's still not right, as it duplicates the
> schema name when creating new functions. I've applied the patch below
> which seems to work in both the create and edit cases:
>

Strange.. I tried creating new functions only while testing my patch and it
never duplicates the schema name.. I tested on Mac (10.6.8)..

Though your patch is making more sense.. (just by reading the code).


>
> diff --git a/pgadmin/dlg/dlgFunction.cpp b/pgadmin/dlg/dlgFunction.cpp
> index d102b97..1d2cc1c 100644
> --- a/pgadmin/dlg/dlgFunction.cpp
> +++ b/pgadmin/dlg/dlgFunction.cpp
> @@ -975,16 +975,19 @@ wxString dlgFunction::GetSql()
> }
> }
>
> -   name = schema->GetQuotedPrefix() + qtIdent(name)
> -  + wxT("(") + GetArgs(false, true) + wxT(")");
>
> if (function)
> {
> +   name = schema->GetQuotedPrefix() + qtIdent(name)
> +   + wxT("(") + GetArgs(false, true) + wxT(")");
> +
> AppendOwnerChange(sql, wxT("FUNCTION ") + name);
> AppendSchemaChange(sql, wxT("FUNCTION ") + name);
> }
> else
> {
> +   name = name + wxT("(") + GetArgs(false, true) + wxT(")");
> +
> if (cbOwner->GetCurrentSelection() > 0)
> AppendOwnerNew(sql, wxT("FUNCTION ") + name);
> }
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
Regards,
Sachin Srivastava
EnterpriseDB, India


Re: [pgadmin-hackers] patch for "Sequence: calculate next value to be expected"

2012-09-05 Thread Dave Page
Hi

On Wed, Sep 5, 2012 at 3:11 AM, Quan Zongliang  wrote:
>
> Sorry, patch again.
> When the sequence is not called, nextValue should be lastValue.
> Otherwise, it is lastValue + increment.

That one still doesn't apply (though, the other one now does).
dos2unix didn't help :-(. Not sure why you're seeing those problems -
I've used VC++ for years without problems - if memory serves, it
normally uses the same lineendings as are already in use.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] little patch for "Detect serial columns from pg_depend" and bugfix

2012-09-05 Thread Dave Page
On Wed, Sep 5, 2012 at 3:39 AM, Quan Zongliang  wrote:
>
> new patch attched.
> I tested it under Cygwin, seems OK.

I got an error on my first test I'm afraid :-(

2012-09-05 14:39:41 QUERY  : Set query (localhost:5432): SELECT classid
  FROM pg_depend
 WHERE refobjid=207478::oid AND refobjsubid = 1 AND objid IN
('pem.agent_id_seq'::regclass,'"pem.agent_id_seq"'::regclass) AND
deptype='a'
2012-09-05 14:39:41 ERROR  : ERROR:  relation "pem.agent_id_seq" does not exist
LINE 3: ...id = 1 AND objid IN ('pem.agent_id_seq'::regclass,'"pem.agen...

How does the attached version of the patch look? I've tweaked the
formatting and removed the excess quotes that seemed to be causing the
issue.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgColumn-v2.diff
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


[pgadmin-hackers] pgAdmin III commit: Display the next expected value for a sequence in t

2012-09-05 Thread Dave Page
Display the next expected value for a sequence in the property list.

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=04271d06c42acab3f5c37943950c160beaa82310
Author: Quan Zongliang 

Modified Files
--
CHANGELOG   |2 ++
pgadmin/include/schema/pgSequence.h |6 +-
pgadmin/schema/pgSequence.cpp   |5 +
3 files changed, 12 insertions(+), 1 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] patch for "Sequence: calculate next value to be expected"

2012-09-05 Thread Dave Page
On Wed, Sep 5, 2012 at 3:04 PM, 权宗亮  wrote:
>
>
> 2012/9/5 Dave Page 
>>
>> Hi
>>
>> On Wed, Sep 5, 2012 at 3:11 AM, Quan Zongliang 
>> wrote:
>> >
>> > Sorry, patch again.
>> > When the sequence is not called, nextValue should be lastValue.
>> > Otherwise, it is lastValue + increment.
>>
>> That one still doesn't apply (though, the other one now does).
>> dos2unix didn't help :-(. Not sure why you're seeing those problems -
>> I've used VC++ for years without problems - if memory serves, it
>> normally uses the same lineendings as are already in use.
>>
>
> That's weird.
>
> I downloaded the file from this mail. It can not be applied.
>
> Before send it, I tried to apply by "git apply" command to make sure it is
> Ok.
>
> Let's try zip file.

That worked. Thanks - patch applied.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] little patch for "Detect serial columns from pg_depend" and bugfix

2012-09-05 Thread 权宗亮
2012/9/5 Dave Page 

> On Wed, Sep 5, 2012 at 3:39 AM, Quan Zongliang 
> wrote:
> >
> > new patch attched.
> > I tested it under Cygwin, seems OK.
>
> I got an error on my first test I'm afraid :-(
>
> 2012-09-05 14:39:41 QUERY  : Set query (localhost:5432): SELECT classid
>   FROM pg_depend
>  WHERE refobjid=207478::oid AND refobjsubid = 1 AND objid IN
> ('pem.agent_id_seq'::regclass,'"pem.agent_id_seq"'::regclass) AND
> deptype='a'
> 2012-09-05 14:39:41 ERROR  : ERROR:  relation "pem.agent_id_seq" does not
> exist
> LINE 3: ...id = 1 AND objid IN ('pem.agent_id_seq'::regclass,'"pem.agen...
>
> How does the attached version of the patch look? I've tweaked the
> formatting and removed the excess quotes that seemed to be causing the
> issue.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

There is a bug in original source.
I will try to fix it tomorrow.

When a column is given a special name.
The serial type can not be reversed correctly.

defination: "c 2" bigserial
display in pgAdmin: "c 2" bigint NOT NULL DEFAULT nextval('pem."t1_c
2_seq"'::regclass)

Because pgAdmin check columns which default value has 'pem.t1_c
2_seq'::regclass
and '"pem.t1_c 2_seq"'::regclass. But second one should be 'pem."t1_c
2_seq"'::regclass

Quan Zongliang


[pgadmin-hackers] pgAdmin III commit: Update chinese translation

2012-09-05 Thread Guillaume Lelarge
Update chinese translation

Branch
--
REL-1_16_0_PATCHES

Details
---
http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=9f85d85b601a304fdab3ff7d2261532f1950a464
Author: Quan Zongliang 

Modified Files
--
i18n/zh_CN/pgadmin3.mo |  Bin 285020 -> 287252 bytes
i18n/zh_CN/pgadmin3.po |  100 +--
2 files changed, 36 insertions(+), 64 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


[pgadmin-hackers] pgAdmin III commit: Update chinese translation

2012-09-05 Thread Guillaume Lelarge
Update chinese translation

Branch
--
master

Details
---
http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=acb8dbb1703a1f0dc4c1e9dff5e00bc8b0baed30
Author: Quan Zongliang 

Modified Files
--
i18n/zh_CN/pgadmin3.mo |  Bin 285020 -> 287252 bytes
i18n/zh_CN/pgadmin3.po |  100 +--
2 files changed, 36 insertions(+), 64 deletions(-)


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] Re: Items missing from some context menus in object browser of v1.16 beta4

2012-09-05 Thread Guillaume Lelarge
On Fri, 2012-08-31 at 23:55 +0200, Guillaume Lelarge wrote:
> On Mon, 2012-08-27 at 16:57 +0200, Erwin Brandstetter wrote:
> > On 27.08.2012 16:37, Erwin Brandstetter wrote:
> > > Aloha!
> > >
> > > I think I ran into this regression with v1.16 beta4 and filed a ticket.
> > > So far I have seen this to affect indexes, primary keys and foreign keys
> > > But *not* tables, views, function, triggers, sequences or types ...
> > >
> > > Added two small screenshots to the ticket to compare 1.4 and 1.16b4
> > > http://code.pgadmin.org/trac/ticket/377
> > >
> > >
> > > Regards
> > > Erwin
> > >
> > >
> > I tried to add more details to the ticket, but 
> > http://code.pgadmin.org/trac/ decided to answer with error messages .. 
> > seems to be offline for now?
> > I'll add my findings here:
> > 
> > Also seems to affect  foreign keys and unique indexes.
> > But *not* tables, views, function, triggers, sequences or types ...
> > Tested with PostgreSQL 9.1 and 8.4
> > 
> > However, in seemingly arbitrary rare cases it works as it should. It's 
> > always the same for all objects under one table so far. I tried but failed 
> > to 
> > spot a difference between the involved tables.
> > 
> 
> As you said, the trac site seems to be done right now, so I can't check
> your screenshots. I know there are some issues with the indexes right
> now. See the thread intitled "pgAdmin III commit: Lots of work on
> domains, and check constraints". I have a patch that may fix your
> issues, but can't check as I can't see your screenshots. I mostly need
> an answer from Dave, to know if I should apply my patch, or revert my
> older patch.
> 

trac is available now, thanks to Dave.

My patch fixes the issue you found.


-- 
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com



-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


Re: [pgadmin-hackers] pgAdmin III commit: Lots of work on domains, and check constraints

2012-09-05 Thread Guillaume Lelarge
On Wed, 2012-09-05 at 08:25 +0100, Dave Page wrote:
> On Tue, Sep 4, 2012 at 10:05 PM, Guillaume Lelarge
>  wrote:
> > On Mon, 2012-09-03 at 22:41 +0200, Guillaume Lelarge wrote:
> >> On Mon, 2012-09-03 at 08:54 +0100, Dave Page wrote:
> >> > On Fri, Aug 31, 2012 at 10:57 PM, Guillaume Lelarge
> >> >  wrote:
> >> > > On Sun, 2012-08-26 at 18:18 +0200, Guillaume Lelarge wrote:
> >> > >> On Mon, 2012-07-23 at 08:38 +0100, Dave Page wrote:
> >> > >> > On Sat, Jul 21, 2012 at 1:40 PM, Guillaume Lelarge
> >> > >> >  wrote:
> >> > >> > > On Wed, 2012-06-06 at 10:50 +0600, Timon wrote:
> >> > >> > >> seems that this commit broke reindexing of selected index. steps 
> >> > >> > >> to reproduce:
> >> > >> > >> 1) create table
> >> > >> > >> 2) create index
> >> > >> > >> 3) select index in object inspector
> >> > >> > >> 4) try to reindex it via maintenance menu item
> >> > >> > >> 5) got error : ERROR:  schema "table_name" does not exist
> >> > >> > >>
> >> > >> > >> and one more crash here
> >> > >> > >> .. same steps as before
> >> > >> > >> 4) try to CLUSTER index
> >> > >> > >> 5) pgadmin simply crashed
> >> > >> > >>
> >> > >> > >
> >> > >> > > OK, I finally got some time to work on this. As Timon said, these 
> >> > >> > > bugs
> >> > >> > > come from the patch "Lots of work on domains, and check 
> >> > >> > > constraints". In
> >> > >> > > this patch, I changed some objects parent class from 
> >> > >> > > pgTableObject to
> >> > >> > > pgSchemaObject. Due to this change, the GetTable() method returns 
> >> > >> > > NULL,
> >> > >> > > which segfaults all statements that try to use the return value 
> >> > >> > > without
> >> > >> > > checking. The two examples above from Timon are exactly this.
> >> > >> > >
> >> > >> > > I don't see many ways to get out of this issue.
> >> > >> > >
> >> > >> > > We could use GetSchema() instead of GetTable(). It works, it's an 
> >> > >> > > easy
> >> > >> > > and small patch. But it'll certainly be a maintenance nightmare 
> >> > >> > > (at
> >> > >> > > least without any comments)
> >> > >> > >
> >> > >> > > We could also revert my patch. It's simple, we loose the feature 
> >> > >> > > of
> >> > >> > > adding as many check constraints as we want to a domain, we loose 
> >> > >> > > the
> >> > >> > > feature of renaming and validating constraints, and we gain a few 
> >> > >> > > bugs.
> >> > >> > >
> >> > >> > > I don't see any other options. My own personal choice would be 
> >> > >> > > the first
> >> > >> > > one (see attached patch). But it's a tough call.
> >> > >> >
> >> > >> > We've run into problems in the past every time we've tried to share 
> >> > >> > a
> >> > >> > sub-class between two parents. I think we should stop trying to do
> >> > >> > that, and just resign ourselves to having to duplicate the class - I
> >> > >> > guess pgCheckConstraint and pgDomainCheckConstraint is the way to 
> >> > >> > go.
> >> > >>
> >> > >> I don't think I'll have the time and motivation to work on this before
> >> > >> we go GA. I guess I'll have to do this later on but in the mean time,
> >> > >> should I revert my commit or apply this patch?
> >> > >>
> >> > >
> >> > > Dave, any comment?
> >> >
> >> > What does the patch look like? As long as it's safe, well commented,
> >> > and overall the new code is an improvement, it seems like it's the
> >> > best option.
> >> >
> >>
> >> I'll work on it tomorrow. If it sounds good enough to me, I'll apply it.
> >> Otherwise, I'll revert my old patch.
> >>
> >
> > Done. I cannot say that it will fix all issues, but at least it fixes
> > the one I know. There's still an issue found by Erwin, that I can't be
> > sure because the trac website is still down.
> 
> Sorry - for some reason when you reported this before I got it into my
> head that you meant redmine.postgresql.org. Trac is fixed now.
> 

Oh OK, no problem. Thanks for fixing this.

The issue found by Erwin is fixed by the patch I applied yesterday. So
we're all good (or more, as good as we could :-/ ).


-- 
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com



-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


[pgadmin-hackers] Re: [pgAdmin III] #377: Regression in 1.16 b4: missing items from context menu for indexes and pkeys

2012-09-05 Thread pgAdmin Trac
#377: Regression in 1.16 b4: missing items from context menu for indexes and
pkeys
+---
 Reporter:  brsa|   Owner:  gleu
 Type:  bug |  Status:  assigned
 Priority:  minor   |   Milestone:  1.16
Component:  pgadmin | Version:  trunk   
 Keywords:  object browser  |Platform:  all 
+---
Changes (by gleu):

  * status:  new => assigned
  * platform:  => all
  * owner:  dpage => gleu
  * milestone:  => 1.16


Comment:

 Fixed in
 
http://git.postgresql.org/gitweb/?p=pgadmin3.git;a=commit;h=9724c2abf1fb3330591eef8567249d7bc367970d

-- 
Ticket URL: 
pgAdmin III 
pgAdmin III

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers


[pgadmin-hackers] Re: [pgAdmin III] #377: Regression in 1.16 b4: missing items from context menu for indexes and pkeys

2012-09-05 Thread pgAdmin Trac
#377: Regression in 1.16 b4: missing items from context menu for indexes and
pkeys
--+-
  Reporter:  brsa |   Owner:  gleu  
  Type:  bug  |  Status:  closed
  Priority:  minor|   Milestone:  1.16  
 Component:  pgadmin  | Version:  trunk 
Resolution:  fixed|Keywords:  object browser
  Platform:  all  |  
--+-
Changes (by gleu):

  * status:  assigned => closed
  * resolution:  => fixed


-- 
Ticket URL: 
pgAdmin III 
pgAdmin III

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers