> Thanks, applied.
>
> Thanks Dave.
Regards,
Nikhils
Hi,
In case of postgres-reg.ini only containing PPAS server information, it is
not being picked up properly by pgAdmin. The issue is in
pgServerFactory::CreateObjects() function. Even though the server
information is being read correctly from the file, it is not being appended
correctly into the b
Thanks Dave.
Regards,
Nikhils
On Thu, May 19, 2011 at 9:15 PM, Dave Page wrote:
> Thanks - applied.
>
> On Wed, May 18, 2011 at 12:03 PM, Nikhil S wrote:
> > Please ignore the last patch. Some unwanted debug changes in there!
> > Please use this one.
> >
> >
Please ignore the last patch. Some unwanted debug changes in there!
Please use this one.
Regards,
Nikhils
On Wed, May 18, 2011 at 5:28 PM, Nikhil S wrote:
> Hi,
>
> So, I changed the locale on my setup to "zh_CN.UTF-8" and tried to restore
> into a database using a backu
Hi,
So, I changed the locale on my setup to "zh_CN.UTF-8" and tried to restore
into a database using a backup from earlier. When I click on "Display
objects" tab, I see an error being displayed, although the actual restore
happens just fine. Note that no error occurs in English locales.
Took me a
>
> When was the last time you ran the bootstrap script?
>
>
Apparently never :P
Did it now and things are kosher. Sorry for the noise.
Regards,
Nikhils
> What issue? If you cannot build png2c, you're not going to be able to
> build the rest of pgAdmin.
>
>
Am using the default configure command:
./configure --with-pgsql=/home/pg/pg_database/
Which completes ok AFAICS.
Then the make errors out:
make all-recursive
make[1]: Entering directory `/h
Hi,
I also face issues while compiling pgadmin on my ubuntu. It has issues
compiling
xtra/png2c directory. Till date, I have circumvented this issue by removing
this directory manually from the Makefile :)
Regards,
Nikhils
On Wed, May 4, 2011 at 11:04 PM, Dave Page wrote:
> On Wed, May 4, 2011
Thanks Dave.
Regards,
Nikhils
On Thu, Apr 28, 2011 at 6:58 PM, Dave Page wrote:
> Thanks, applied.
>
> On Thu, Apr 28, 2011 at 10:59 AM, Nikhil S wrote:
> > Hi,
> >
> >>
> >> The pgAdmin source base is peppered with references to a non-existent
> >
Hi,
> The pgAdmin source base is peppered with references to a non-existent
> "proargdefvals" attribute.
Ok, this was being used in AS83, so we cannot remove these references
completely.
> The FEATURE_FUNCTION_DEFAULTS feature will not get set because of this
> ever. This patch replaces the r
Hi,
The pgAdmin source base is peppered with references to a non-existent
"proargdefvals" attribute. The FEATURE_FUNCTION_DEFAULTS feature will not
get set because of this ever. This patch replaces the references to this
attribute by the valid "proargdefaults" attribute.
Regards,
Nikhils
diff --g
>
> Thanks, applied.
>
>
Thanks Dave. How's the lunch on the cruise? ;)
Regards,
Nikhils
Hi,
In PPAS 90, if an SPL-function has both an OUT-parameter and a return value
(which is not possible on PostgreSQL otherwise), the return value is
transformed into an extra OUT-parameter named "_retval_". Although we fixed
the normal code path a while back, the debugger still remains dazed and
c
Thanks, applied.
>
>
Thanks Dave.
Regards,
Nikhils
> On Thu, Mar 31, 2011 at 8:15 AM, Nikhil S wrote:
> > Hi,
> >
> > Consider the following PPAS 9.0 function:
> >
> > CREATE OR REPLACE FUNCTION TEST_in_inout_out(A IN INT, B IN OUT INT, C
> OUT
Hi,
Consider the following PPAS 9.0 function:
CREATE OR REPLACE FUNCTION TEST_in_inout_out(A IN INT, B IN OUT INT, C OUT
INT) RETURN INT
IS
D INT;
BEGIN
D := A + B + C;
RETURN D;
END;
When I click on properties and try to assign a comment to this function, it
errors out. In PPAS 9.
> Damn that Heikki bloke :-)
>
>
Hehe :)
> Thanks - applied with a minor change to the variable name.
>
>
Thanks Dave.
Regards,
Nikhils
Hi,
In PPAS 9.0, two new functions have been introduced to retrieve information
related to package elements. We need to incorporate the same as the old sql
query will not work anymore.
Regards,
Nikhils
diff --git a/pgadmin/schema/edbPackage.cpp b/pgadmin/schema/edbPackage.cpp
index f1cec72..d703e
> Thanks - applied (with a minor tweak to make it work) :-p
>
>
Heh, thanks Dave :)
Regards,
Nikhils
> On Fri, Feb 25, 2011 at 3:05 PM, Nikhil S wrote:
> > Hi,
> >
> > If we use pgadmin III to browse a PPAS database that was installed in
> > Postgresql mode
Hi,
If we use pgadmin III to browse a PPAS database that was installed in
Postgresql mode, the "sys" and "dbo" system schemas appear incorrectly under
the normal user "Schemas" hierarchy. The issue is occurring because the
current sql in pgSchemaBaseFactory::CreateObjects() which tries to avoid
sh
Thanks Dave!
Regards,
Nikhils
On Wed, Feb 23, 2011 at 3:57 PM, Dave Page wrote:
> Thanks, patch applied to trunk and 1.12.
>
> On Mon, Feb 21, 2011 at 9:17 AM, Nikhil S wrote:
> > Hi,
> >
> > In EDBAS 9.0, following notable restructuring has been done with res
ems low risk.
>
> +1 from the patch-submitter (if it counts ;))
Regards,
Nikhils
> On Mon, Feb 21, 2011 at 9:17 AM, Nikhil S wrote:
> > Hi,
> >
> > In EDBAS 9.0, following notable restructuring has been done with respect
> to
> > functions and procedures. We need
Hi,
In EDBAS 9.0, following notable restructuring has been done with respect to
functions and procedures. We need to adopt the same in the pgAdmin code
base. Note that these changes make EDBAS funcs/procs behave more like native
Postgres functions which is a good thing:
* To debug edb-SPL functio
Thanks Dave!
> On Mon, Feb 14, 2011 at 12:53 PM, Nikhil S wrote:
> >
> >> > Ok. One way that I can think of is that since we have the typeoids
> >> > handily
> >> > available, we can check the same and see if it is of stringlike type
> >>
> > Ok. One way that I can think of is that since we have the typeoids
> handily
> > available, we can check the same and see if it is of stringlike type
> > (PGOID_TYPE_CHAR, PGOID_TYPE_NAME, PGOID_TYPE_TEXT, etc..). If yes, then
> we
> > retain the "", else we ignore it. Sounds reasonable?
>
> Ye
Hi,
> But I guess you mean, we should find a solution more on the pgadmin side
> > instead of tinkering with the backend?
>
> Yes.
>
>
Ok. One way that I can think of is that since we have the typeoids handily
available, we can check the same and see if it is of stringlike type
(PGOID_TYPE_CHAR, P
Hi Prajwal,
The issue just pops up a benign error message. If you continue further you
should be able to proceed with the restore process.
Regards,
Nkhils
On Sun, Feb 13, 2011 at 2:25 PM, Prajwal wrote:
>
> Hi Nikhil,
>
> I am new to PostgreSQL.
> I do need to restore the database on Postgres
> > Hmmm, well variables can default to NULL too. The backend code tries to
> > track those variables which default to NULL or to other values. For the
> > rest, it defaults them to "". It then uses construct_md_array to generate
> > the output string for type TEXTOID. Dunno if we can have nothing
>
> > Note that if there are no default values, the the defvals column is
> > completely empty. Now why we see the "" for non-default arguments - the
> > issue seems to be on the server side in the contrib module calls to
> compute
> > the default values.
>
> We need to change that then - we can't
Hi,
On Thu, Feb 10, 2011 at 8:48 PM, Dave Page wrote:
> On Mon, Feb 7, 2011 at 9:03 AM, Nikhil S wrote:
> > One side-effect of this feature is that earlier where non-default
> variables
> > appeared as empty, they will now appear with values "". This will happen
>
> Thanks - applied.
>
> Thanks Dave.
Regards,
Nikhils
> On Mon, Feb 7, 2011 at 1:01 PM, Nikhil S wrote:
> > Hi,
> >
> > If one clicks on Postgres (non EDB) database and tries to expand the
> schema
> > tab, then the current git head spits out an erro
> Well, the SQL does get fired against a PG database in the EDBAS mode for
> me. I too was puzzled about the minimum version check being EDBAS specific.
>
>
Just checked. The version checker function checks for the version number and
also for a bool which is set to true in EDBAS mode. So yeah, this
> I"m not sure I understand. You first said that the bug is on regular
> PostgreSQL (and I can't reproduce it on 9.0 regular PostgreSQL). When
> you explain the bug and if I read correctly your patch, it fixes EDB
> database only.
>
> So is it a fix for EDB databases or PostgreSQL databases?
>
>
We
Hi,
If one clicks on Postgres (non EDB) database and tries to expand the schema
tab, then the current git head spits out an error. The offending query
contains the following comparison
protype = 1;
protype is of type char, so it expects the RHS to be a char. However this
works ok against an EDB
Hi,
The debugger, when it is invoked on a function or a procedure, provides a
dialogue box to fill up values for the arguments. In case the user has
created them with some default values assigned to some of the parameters,
then they would expect that the debugger pre-populates them with those
defa
>
> > When creating a new job, if one directly clicks on the Schedules tab and
> > tries to add one, then the date picker does not work. I was trying to see
> > why this is so for quite a while. Then I realized that adding a schedule
> or
> > a step before the job has been actually created does no
Hi,
When creating a new job, if one directly clicks on the Schedules tab and
tries to add one, then the date picker does not work. I was trying to see
why this is so for quite a while. Then I realized that adding a schedule or
a step before the job has been actually created does not make sense.
H
> > If one right clicks on database and goes to properties, there the
> "Default
> > Privileges" tab does not seem to contain the 'public' schema
> pre-selected.
> > It is so the case in the normal "Privileges" for example. This patch
> > pre-populates the 'public' schema for the default privileges
> Nah - I meant to do it yesterday, but ended up spending all day trying
> to figure out why I couldn't detect a focus event on a notebook page
> properly.
>
> Committed - thanks!
>
>
Thanks Dave.
Regards,
Nikhils
Hi,
If one right clicks on database and goes to properties, there the "Default
Privileges" tab does not seem to contain the 'public' schema pre-selected.
It is so the case in the normal "Privileges" for example. This patch
pre-populates the 'public' schema for the default privileges case too.
Reg
Hi Dave,
>
> > I'm inclined to consider this a bug, as my failure to update this
> > prior to the release of 1.12 means that our support for that feature
> > is essentially broken.
> >
> > Does anyone object, before I commit it to 1.12?
> >
>
> No objection here.
>
>
>
Aye from the patch submitter
Hi,
Since EDB AS 8.4, we support synonyms for functions and procedures. I
checked support for both plpgsql functions and edbspl functions and
procedures. However the create synonym dialogue only provides "Sequence,
Synonym, Table and View" as target types. We need to add functions and
procedures t
> Thanks. This seems to be a bug in fact, as it could mis-identify a
> function that returns void as a procedure.
>
> Applied for 1.12.3 and master.
>
>
Thanks Dave.
Regards,
Nikhils
Hi,
With the latest refactorings in the EDBAS90 source base, procedures (CREATE
PROCEDURE objects) can have non void return types in some cases. For
example:
edb=# create or replace procedure set_Order (
v_indexINOUT integer
) AS
counterinteger;
BEGIN
counter := 0;
v_
> Just applied.
>
> This issue was bugging me too, but I couldn't find a proper fix. So,
> thanks a lot for this :)
>
>
Glad to be of some help :). Thanks Guillaume.
Regards,
Nikhils
Hi,
The following set of operations induce an error:
1. Create a backup file /tmp/pg.backup of an existing database
2. Create a new database
3. Right click and select restore database by specifying this file
4. Clicking on "Display Objects" causes the following error: "An error has
occurred: Sche
> Seems good enough. Commited. Thanks a lot :)
>
>
Thanks a lot!
Regards,
Nikhils
Hi,
The following set of operations induce a crash in the latest git code base:
1. Open pgAdmin III
2. Go to File Menu->Open Postgressql.conf
3. From data folder select pg_hba.conf file and open it
4. The file opens successfully
5. Now select any setting ("port" for example) and add a Value and C
47 matches
Mail list logo
