Re: [Spacewalk-devel] PGPORT: Query tagging commits to cherry-pick into master

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 25 Mar 2009 16:54:59 +0100 Michael Mraka wrote: > Devan Goodwin wrote: > % I think cherry-picking these commits would help reduce the > conflicts in % the pgsql branch: > % > % 22fae9993b39a35f882131ce7ae5c4b9024744cf > % > % 5e147ad535493c

Re: [Spacewalk-devel] PGPORT: Query tagging commits to cherry-pick into master

Devan Goodwin wrote: % I think cherry-picking these commits would help reduce the conflicts in % the pgsql branch: % % 22fae9993b39a35f882131ce7ae5c4b9024744cf % % 5e147ad535493c8209b28cb3c8d21bc1e3a78893 % % 9cad4715e3e3945a886f0581b1eb6f00d2468620 At first someone should fix bugs like this: @

Re: [Spacewalk-devel] PGPORT: Query tagging commits to cherry-pick into master

On Tue, Mar 24, 2009 at 1:20 PM, Devan Goodwin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I think cherry-picking these commits would help reduce the conflicts in > the pgsql branch: > > 22fae9993b39a35f882131ce7ae5c4b9024744cf > > 5e147ad535493c8209b28cb3c8d21bc1e3a78893 > > 9cad

[Spacewalk-devel] PGPORT: Query tagging commits to cherry-pick into master

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think cherry-picking these commits would help reduce the conflicts in the pgsql branch: 22fae9993b39a35f882131ce7ae5c4b9024744cf 5e147ad535493c8209b28cb3c8d21bc1e3a78893 9cad4715e3e3945a886f0581b1eb6f00d2468620 da98013f69a90571cd2080c381f0e293153

Re: [Spacewalk-devel] PGPORT: additional packages

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 13 Mar 2009 19:18:22 +0530 Vikram Rai wrote: > Hi Devan, > > Attached are additional packages that need to be checked into the > repository. > Since I do not have rights to check them in, could you please check > them into the following loca

Re: [Spacewalk-devel] PGPORT: additional packages

On Fri, Mar 13, 2009 at 9:48 AM, Vikram Rai wrote: > Hi Devan, > > Attached are additional packages that need to be checked into the > repository. > Since I do not have rights to check them in, could you please check them > into the following location: > > spacewalk/schema/spacewalk/postgresql/pac

[Spacewalk-devel] PGPORT: additional packages

Hi Devan, Attached are additional packages that need to be checked into the repository. Since I do not have rights to check them in, could you please check them into the following location: spacewalk/schema/spacewalk/postgresql/packages/ Thanks Vikram Rai EnterpriseDB rhn_packages.tar.gz Desc

Re: [Spacewalk-devel] PGPORT: PostgreSQL 8.3 Problem?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 04 Mar 2009 14:30:39 +0530 tushar wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In addition to that, this link > http://www.postgresql.org/docs/8.3/static/release-8-3.html would be > helpful. > Thanks for the info guys, will

Re: [Spacewalk-devel] PGPORT: master to pgsql merge: schema changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Mar 2009 15:53:11 +0530 Gurjeet Singh wrote: > Hi Devan, > > In rhnSsmOperation.sql column user_id references rhnUser(id). > rhnUser table does not exist in Postgres port. > > A little digging shows that in Oracle schema rhnUser i

Re: [Spacewalk-devel] PGPORT: master to pgsql merge: schema changes

Hi Devan, In rhnSsmOperation.sql column user_id references rhnUser(id). rhnUser table does not exist in Postgres port. A little digging shows that in Oracle schema rhnUser is a synonym for web_contact. So in the Postgres port I have made that column reference web_contact(id). Hope it's ok

Re: [Spacewalk-devel] PGPORT: PostgreSQL 8.3 Problem?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In addition to that, this link http://www.postgresql.org/docs/8.3/static/release-8-3.html would be helpful. Gurjeet Singh wrote: > On Wed, Mar 4, 2009 at 11:21 AM, tushar @gmail.com > wrote: > > -BEGIN PG

Re: [Spacewalk-devel] PGPORT: PostgreSQL 8.3 Problem?

On Wed, Mar 4, 2009 at 11:21 AM, tushar wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Devan Goodwin wrote: > > Suspect we might have something in our schema that doesn't work on 8.3, > > doing some testing on fedora and hit this: > > > > psql:tables/rhn_contact_groups.sql:45: ERROR

Re: [Spacewalk-devel] PGPORT: PostgreSQL 8.3 Problem?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Devan Goodwin wrote: > Suspect we might have something in our schema that doesn't work on 8.3, > doing some testing on fedora and hit this: > > psql:tables/rhn_contact_groups.sql:45: ERROR: operator does not exist: > character = integer HINT: No ope

[Spacewalk-devel] PGPORT: PostgreSQL 8.3 Problem?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Suspect we might have something in our schema that doesn't work on 8.3, doing some testing on fedora and hit this: psql:tables/rhn_contact_groups.sql:45: ERROR: operator does not exist: character = integer HINT: No operator matches the given name an

Re: [Spacewalk-devel] PGPORT

On Mon, Mar 2, 2009 at 9:16 PM, Jeff Ortel wrote: > > > Gurjeet Singh wrote: > >> >> I am abandoning any efforts in creating a common/ directory for now, in >> favour of query tagging efforts. Jeff/Devan, please let me know if you wish >> to prioritize this. Will pick this up again if we are able

[Spacewalk-devel] PGPORT

Hi, The first set of files for query tagging have been pushed to the git repository. spacewalk/backend/server/test/unit-test/test_rhnServerGroup.py spacewalk/backend/server/test/test_leak3.py spacewalk/backend/server/test/test_leak2.py spacewalk/backend/server/test/test_leak.py spacewalk/backend/

Re: [Spacewalk-devel] PGPORT

Gurjeet Singh wrote: Did some preliminary analysis and following are the results: Total 64 views/ files have been ported. Only two files are exactly same. There are 23 files (including the above two) which have less than 10 lines of difference. These differences are mostly either nvl(), de

Re: [Spacewalk-devel] PGPORT: git merge problems, rhnsat schema diff

On Mon, Mar 2, 2009 at 7:32 PM, Devan Goodwin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Muhammad: I think you may have accidentally done a master to pgsql > merge for me. :) Ooops :) > > > > http://hosted2.fedoraproject.org/cgit/spacewalk.git/commit/?h=pgsql&id=20a473edd51c

[Spacewalk-devel] PGPORT: git merge problems, rhnsat schema diff

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Muhammad: I think you may have accidentally done a master to pgsql merge for me. :) http://hosted2.fedoraproject.org/cgit/spacewalk.git/commit/?h=pgsql&id=20a473edd51cf26e19220b8a048b2e250606b047 It appears the merge was clean, no conflicts, thus wh

Re: [Spacewalk-devel] PGPORT: Triggers migration

Very nice! Thanks Muhammad. Muhammad Farrukh wrote: Hi All, All the triggers have been migrated over to postgresql and main.sql has also been changed to accommodate the trigger files. The wiki has also been updated. Regards, Farrukh ---

Re: [Spacewalk-devel] PGPORT

Great! Thanks for the update. Gurjeet Singh wrote: The three pending views have also been ported and pushed to repo. Two of these have been uncommented from main.sql, and the one that is left in comments is because it uses rhn_channel package, which hasn't been ported yet. With this, portin

[Spacewalk-devel] PGPORT: Triggers migration

Hi All, All the triggers have been migrated over to postgresql and main.sql has also been changed to accommodate the trigger files. The wiki has also been updated. Regards, Farrukh ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www

Re: [Spacewalk-devel] PGPORT

Did some preliminary analysis and following are the results: Total 64 views/ files have been ported. Only two files are exactly same. There are 23 files (including the above two) which have less than 10 lines of difference. These differences are mostly either nvl(), decode(), 'show error', or co

Re: [Spacewalk-devel] PGPORT

The three pending views have also been ported and pushed to repo. Two of these have been uncommented from main.sql, and the one that is left in comments is because it uses rhn_channel package, which hasn't been ported yet. With this, porting of viws is complete. Now as per Jeff's comments on IRC,

Re: [Spacewalk-devel] PGPORT (regarding queries)

Hey Vikram, Thanks for putting the samples together. See below. -jeff Vikram Rai wrote: Hi, I have updated wiki with the process to tag the queries. The below link would be used to track changes: https://fedorahosted.org/spacewalk/wiki/PgportQueries

Re: [Spacewalk-devel] PGPORT (regarding queries)

Hi, I have updated wiki with the process to tag the queries. The below link would be used to track changes: https://fedorahosted.org/spacewalk/wiki/PgportQueries And the following link has examples for query tagging: https://fedorahosted.org/spacewalk/wiki/QueryTaggingExamples Regards, Vikram

[Spacewalk-devel] PGPORT: EVR_T object ported

Hi All, The object EVR_T has been ported to Postgres, and resides in schema/spacewalk/postgres/class/evr_t.sql Porting the object involved .) Creating a TYPE evr_t. .) Creating overloaded operators to compare two evr_t objects; these will enable the ORDER BY to work on these objects. .)

Re: [Spacewalk-devel] PGPORT (regarding queries)

Here is where the query type numbers are defined: https://fedorahosted.org/spacewalk/wiki/PostgresTechnicalApproach --- Vikram Rai wrote: > Hi, > > We have started looking at the queries that need to be tagged

[Spacewalk-devel] PGPORT: guidelines for porting Packages

Since the application code and the database views calls the packaged functions as: call package_name.function_name() OR select package_name.function_name() and since such call sites are numerous, it is desirable to not change each and every call site. Hence the approach taken to tackle this is

Re: [Spacewalk-devel] PGPORT (regarding queries)

Please see comments inline and marked as Vik>> On Tue, Feb 24, 2009 at 9:00 PM, Jeff Ortel wrote: > Thanks for sending this out. > > A couple of questions: > > * Why did we abandon the tagging using number (1-5) and decide to go with > letters/words. > This seems more prone to error. Vik >> W

Re: [Spacewalk-devel] PGPORT (regarding queries)

Thanks for sending this out. A couple of questions: * Why did we abandon the tagging using number (1-5) and decide to go with letters/words. This seems more prone to error. * Is the line # relative to the query? Like PGPORT_xx:3 for line #3 in the query? or is it the absolute line # in th

Re: [Spacewalk-devel] PGPORT (regarding queries)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Feb 2009 19:35:44 +0530 Vikram Rai wrote: > Hi, > > We have started looking at the queries that need to be tagged. > In the initial stages of going through these queries we found a > couple of things and some ways we can tag them.

[Spacewalk-devel] PGPORT (regarding queries)

Hi, We have started looking at the queries that need to be tagged. In the initial stages of going through these queries we found a couple of things and some ways we can tag them. Keeping in mind the diversity and complexity of the some of the queries we have divided them into four cat

Re: [Spacewalk-devel] PGPORT

Great! Gurjeet Singh wrote: Done with almost all the views. Only three views are left for porting. Apart from these three, 18 views that have been converted had to be commented from the main.sql since these views use either packages or the object EVR_T. So started on package migration. The c

Re: [Spacewalk-devel] PGPORT

Done with almost all the views. Only three views are left for porting. Apart from these three, 18 views that have been converted had to be commented from the main.sql since these views use either packages or the object EVR_T. So started on package migration. The changes have been pushed to pgsql b

[Spacewalk-devel] PGPORT: empty_blob() Commit For Review

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ran into an issue in satCerts.py with the use of empty_blob(), being used to insert into a table with a blob column which has a not null constraint. In PostgreSQL this column becomes a "bytea". First tried changing it to just '' but this breaks for O

Re: [Spacewalk-devel] PGPORT: master to pgsql merge: schema changes

Vikram, apparently, there are quite a few schema changes and additions in this merge. Can you please look at the diff and make appropriate changes to the postgresql/tables/ directory? Some tables have been replaced by views, I'll take care of porting these views. Farrukh, we have some procedures

[Spacewalk-devel] PGPORT: master to pgsql merge: schema changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just did a master to pgsql merge this morning and about to push the results. Here's a diff of what's changed in the schema since the last merge. (only on the rhnsat/ subdir, left the rest out as it includes upgrades and such which we're not interested

[Spacewalk-devel] PGPORT

All, I've added the view migration tracking table ( https://fedorahosted.org/spacewalk/wiki/PgportViews ) and linked to the tasks ( https://fedorahosted.org/spacewalk/wiki/PostgresTasks ) page. This table __is__ ordered according to dependency. -jeff ___

Re: [Spacewalk-devel] PGPORT: Instructions for porting procedures/functions

Great! I added a link in the tasks page ( https://fedorahosted.org/spacewalk/wiki/PostgresTasks ) and added some description. George, please add to the project plan "Tasks and Milestones". Muhammad Farrukh wrote: I've created a new wiki page to track the procedures/functions migration: https

Re: [Spacewalk-devel] PGPORT: Instructions for porting procedures/functions

I've created a new wiki page to track the procedures/functions migration: https://fedorahosted.org/spacewalk/wiki/PgportProcedures Please update the wiki page if you have worked or are working on any. Regards, Farrukh On Tue, Feb 17, 2009 at 3:26 PM, Muhammad Farrukh < muhammad.farr...@enterpr

Re: [Spacewalk-devel] PGPORT: CONNECT BY queries

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just an refresher, before proceeding with a solution for forked queries inside Python, with what we know now is the below still a problem requiring forking them? Perl and Java are relatively well setup to support forked queries but Python will require

Re: [Spacewalk-devel] PGPORT: Instructions for porting procedures/functions

On Thu, Feb 12, 2009 at 4:26 PM, Gurjeet Singh < gurjeet.si...@enterprisedb.com> wrote: > I am using upper case to highlight the usage of keywords. We otherwise > should not be using uppercase in this porting effort. > > .) Datatypes: > > We follow the same rules for converting datatypes that

Re: [Spacewalk-devel] PGPORT: Instructions for porting procedures/functions

On Thu, Feb 12, 2009 at 5:47 PM, tushar wrote: > Gurjeet Singh wrote: > >> I am using upper case to highlight the usage of keywords. We otherwise >> should not be using uppercase in this porting effort. >> >> .) Datatypes: >> >>We follow the same rules for converting datatypes that we followe

Re: [Spacewalk-devel] PGPORT: Instructions for porting procedures/functions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for another great guide! Devan On Thu, 12 Feb 2009 16:56:54 +0530 Gurjeet Singh wrote: > I am using upper case to highlight the usage of keywords. We otherwise > should not be using uppercase in this porting effort. > > .) Datatypes: > >

Re: [Spacewalk-devel] PGPORT: Instructions for porting procedures/functions

Gurjeet Singh wrote: I am using upper case to highlight the usage of keywords. We otherwise should not be using uppercase in this porting effort. .) Datatypes: We follow the same rules for converting datatypes that we followed in porting tables. number => numeric (for now, until we co

[Spacewalk-devel] PGPORT: Instructions for porting procedures/functions

I am using upper case to highlight the usage of keywords. We otherwise should not be using uppercase in this porting effort. .) Datatypes: We follow the same rules for converting datatypes that we followed in porting tables. number => numeric (for now, until we convert tables' number colu

Re: [Spacewalk-devel] PGPORT: Orafce fixes

Great Bruce! Thanks. Bruce Momjian wrote: The Orafce community has fixed their code so it runs fine on Postgres 8.1. Right now there is no orafce official release with these fixes so we should use their CVS HEAD for our development. Once we near completion we can request an official release t

Re: [Spacewalk-devel] PGPORT: CONNECT BY queries

On Fri, Feb 6, 2009 at 7:50 PM, Devan Goodwin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, 6 Feb 2009 19:37:28 +0530 > Gurjeet Singh wrote: > > > > > > > Hmm.. Although that is doable, I haven't thought about that. The way > > I saw it was that we'd have a IF(ORACLE) CONN

Re: [Spacewalk-devel] PGPORT: CONNECT BY queries

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Feb 2009 19:37:28 +0530 Gurjeet Singh wrote: > > > Hmm.. Although that is doable, I haven't thought about that. The way > I saw it was that we'd have a IF(ORACLE) CONNECT BY ELSE IF(POSTGRES) > CALL FUNCTION END kinda code... > > Thinking

Re: [Spacewalk-devel] PGPORT: CONNECT BY queries

On Fri, Feb 6, 2009 at 7:30 PM, Devan Goodwin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, 6 Feb 2009 18:22:49 +0530 > Gurjeet Singh wrote: > > > Hi All, > > > > As I mentioned in the last conference call, I could not implement > > a workaround for CONNECT BY in plpgs

[Spacewalk-devel] PGPORT: meeting minutes?

On Fri, Feb 06, 2009 at 06:22:49PM +0530, Gurjeet Singh wrote: > Hi All, > > As I mentioned in the last conference call, I could not implement a > workaround for CONNECT BY in plpgsql; that was because of a limitation in Hello, not specific to the CONNECT BY issue -- are there meeting minute

Re: [Spacewalk-devel] PGPORT: CONNECT BY queries

2009/2/6 Michael Mraka > > CONNECT BY creates a "tree select". Can the above select with > rhn_get_action_prerequisites() handle multi level dependencies as well? > I.e. for >id prerequisite >1 NULL >2 1 >3 1 >21 NULL >22

Re: [Spacewalk-devel] PGPORT: CONNECT BY queries

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Feb 2009 18:22:49 +0530 Gurjeet Singh wrote: > Hi All, > > As I mentioned in the last conference call, I could not implement > a workaround for CONNECT BY in plpgsql; that was because of a > limitation in the way plpgsql handles the ps

Re: [Spacewalk-devel] PGPORT: CONNECT BY queries

Gurjeet Singh wrote: % Hi All, % % As I mentioned in the last conference call, I could not implement a % workaround for CONNECT BY in plpgsql; that was because of a limitation in % the way plpgsql handles the pseudo datatype RECORD. ... % and both these instances SELECT the same data: given an

[Spacewalk-devel] PGPORT: CONNECT BY queries

Hi All, As I mentioned in the last conference call, I could not implement a workaround for CONNECT BY in plpgsql; that was because of a limitation in the way plpgsql handles the pseudo datatype RECORD. So, I turned to implementing it as an add-on in C. But I wanted to actually see how muc

[Spacewalk-devel] PGPORT: Orafce fixes

The Orafce community has fixed their code so it runs fine on Postgres 8.1. Right now there is no orafce official release with these fixes so we should use their CVS HEAD for our development. Once we near completion we can request an official release that contains all the fixes. I have updated th

Re: [Spacewalk-devel] PGPORT: Porting NUMBER datatype to Postgres

Maybe we should convert the tables based on dependency. Attached are the tables names as ordered in the universe-satellite.sql that is created by the makefile. Partha Aji wrote: I generated an initial list of columns that were converted to bigint, integer and float from NUMERIC that ora2pg

Re: [Spacewalk-devel] PGPORT: Porting NUMBER datatype to Postgres

On Wed, Feb 04, 2009 at 03:44:54PM -0500, Jason Dobies wrote: > > A lot of the primary keys are put into various tablespaces such as > [[2m_tbs]], [[4m_tbs]], [[64k_tbs]]. > > Is the intention that those tablespaces indicate roughly the size that > each key could occupy? Is it possible to use thos

Re: [Spacewalk-devel] PGPORT: Porting NUMBER datatype to Postgres

I generated an initial list of columns that were converted to bigint, integer and float from NUMERIC that ora2pg spit out a while ago I have attached the file.. It uses the space separated format TableName ColumnName DataType for example: db_change_script_expanded line_no bigint rhna

Re: [Spacewalk-devel] PGPORT: Porting NUMBER datatype to Postgres

> Hi All, > > Porting Oracle's NUMBER datatype to Postgres' numeric datatype > might seem very straight-forward. But the NUMERIC datatype is known to > have a huge performance impact on the query run-times. > > So we have decided to convert the number columns to > SMALLINT/INTEGER/BIGINT

[Spacewalk-devel] PGPORT: Porting tables; contributions needed

All, Let's keep track of who is working which tables via the wiki: https://fedorahosted.org/spacewalk/wiki/PgportTables. I'm already loosing track trying to follow the posts on the list. Please go update with tables you are working on. Thanks, -jeff Devan Goodwin wrote: -BEGIN PGP SI

Re: [Spacewalk-devel] PGPORT: Another porting request.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Feb 2009 11:01:45 +0100 Michael Mraka wrote: > % > Can't we just use those two fields, in the ORDER BY query? > % > % What two fields? > > order by decode(version, null, 1, 0), version Tried this before I went to the case but it didn't

Re: [Spacewalk-devel] PGPORT: Another porting request.

Devan Goodwin wrote: % -BEGIN PGP SIGNED MESSAGE- % Hash: SHA1 % % On Tue, 3 Feb 2009 20:24:06 +0100 % Jan Pazdziora wrote: % % > On Tue, Feb 03, 2009 at 02:48:15PM -0400, Devan Goodwin wrote: % > >FROM rhnSatelliteCert % > > WHERE label = :label % > > - - ORDER BY vers

Re: [Spacewalk-devel] PGPORT: Another porting request.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Feb 2009 20:24:06 +0100 Jan Pazdziora wrote: > On Tue, Feb 03, 2009 at 02:48:15PM -0400, Devan Goodwin wrote: > >FROM rhnSatelliteCert > > WHERE label = :label > > - - ORDER BY version DESC NULLS LAST > > + ORDER BY >

Re: [Spacewalk-devel] PGPORT: Another porting request.

On Tue, Feb 03, 2009 at 02:48:15PM -0400, Devan Goodwin wrote: >FROM rhnSatelliteCert > WHERE label = :label > - - ORDER BY version DESC NULLS LAST > + ORDER BY > + CASE WHEN version IS NULL > +THEN -1 > +ELSE version > + END > +DE

Re: [Spacewalk-devel] PGPORT: Another porting request.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Feb 2009 19:11:39 +0530 Gurjeet Singh wrote: > On Tue, Feb 3, 2009 at 6:34 PM, Jan Pazdziora > wrote: > > > On Tue, Feb 03, 2009 at 06:26:19PM +0530, Gurjeet Singh wrote: > > > > > > > > How about > > > > > > > >order by decode(ve

[Spacewalk-devel] PGPORT: iteration #2 review.

All, We're in the process of formalizing the analysis/planning for the postgres porting project. The project plan specifies this work to be done in several iterations. The 1st iteration generally consists of creating the postges schema and porting those stored procedures not associated with

Re: [Spacewalk-devel] PGPORT: Another porting request.

On Tue, Feb 3, 2009 at 6:34 PM, Jan Pazdziora wrote: > On Tue, Feb 03, 2009 at 06:26:19PM +0530, Gurjeet Singh wrote: > > > > > > How about > > > > > >order by decode(version, null, 1, 0), version > > > > Yup... that'll work, but will mess up the ordering if more than one of > > version's

Re: [Spacewalk-devel] PGPORT: Another porting request.

On Tue, Feb 03, 2009 at 06:26:19PM +0530, Gurjeet Singh wrote: > > > > How about > > > >order by decode(version, null, 1, 0), version > > Yup... that'll work, but will mess up the ordering if more than one of > version's values is non-null. > > SQL> select * from t order by decode( a, nul

Re: [Spacewalk-devel] PGPORT: Another porting request.

On Tue, Feb 3, 2009 at 5:40 PM, Jan Pazdziora wrote: > On Tue, Feb 03, 2009 at 04:21:29PM +0530, Gurjeet Singh wrote: > > > > > > _query_latest_version = rhnSQL.Statement(""" > > >SELECT nvl(version, 0) version, version orig_version, cert, > > > TO_CHAR(issued, '-MM-DD HH24:MI:S

Re: [Spacewalk-devel] PGPORT: Another porting request.

On Tue, Feb 03, 2009 at 04:21:29PM +0530, Gurjeet Singh wrote: > > > > _query_latest_version = rhnSQL.Statement(""" > >SELECT nvl(version, 0) version, version orig_version, cert, > > TO_CHAR(issued, '-MM-DD HH24:MI:SS') issued, > > TO_CHAR(expires, '-MM-DD HH24:MI:SS

Re: [Spacewalk-devel] PGPORT: Another porting request.

On Tue, Feb 3, 2009 at 7:00 AM, Devan Goodwin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey guys, blocked on another spot in the installer and wanted to queue > these items up for porting: > > Out of backend/satellite_tools/satCerts.py: > > _query_latest_version = rhnSQL.Statem

[Spacewalk-devel] PGPORT: Porting NUMBER datatype to Postgres

Hi All, Porting Oracle's NUMBER datatype to Postgres' numeric datatype might seem very straight-forward. But the NUMERIC datatype is known to have a huge performance impact on the query run-times. So we have decided to convert the number columns to SMALLINT/INTEGER/BIGINT wherever possibl

Re: [Spacewalk-devel] PGPORT: Another porting request.

On Mon, Feb 02, 2009 at 09:30:17PM -0400, Devan Goodwin wrote: > > Hey guys, blocked on another spot in the installer and wanted to queue > these items up for porting: > > Out of backend/satellite_tools/satCerts.py: > > _query_latest_version = rhnSQL.Statement(""" > SELECT nvl(version, 0) ve

[Spacewalk-devel] PGPORT: Porting tables; contributions needed

Hi All, I have migrated the following DB objects to work okay with Postgres: ./procs/create_first_org.sql ./tables/web_customer.sql ./tables/rhnUserGroupType.sql ./tables/rhnUserGroup.sql ./tables/rhnOrgQuota.sql ./tables/rhnUserGroup_sequences.sql ./tables/rhnServerGroupType.sql ./tables/rhn

[Spacewalk-devel] PGPORT: Another porting request.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey guys, blocked on another spot in the installer and wanted to queue these items up for porting: Out of backend/satellite_tools/satCerts.py: _query_latest_version = rhnSQL.Statement(""" SELECT nvl(version, 0) version, version orig_version, cert

Re: [Spacewalk-devel] PGPORT: Oracle's VARCHAR2 vs. VARCHAR

On Fri, Jan 30, 2009 at 12:28:55PM +0530, Gurjeet Singh wrote: > In the teleconference yesterday I suggested converting VARCHAR2 usage in > Oracle schema to VARCHAR as well. But the Oracle 11g docs seem to suggest Similar answer to the DECODE one -- while it might be a noble goal to get away from

[Spacewalk-devel] PGPORT: Oracle's VARCHAR2 vs. VARCHAR

In the teleconference yesterday I suggested converting VARCHAR2 usage in Oracle schema to VARCHAR as well. But the Oracle 11g docs seem to suggest otherwise: http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements001.htm#sthref77 They keep saying VARCHAR _will_ be treated diff

[Spacewalk-devel] PGPORT: Orafce

I talked to the Orafce author. He says Orace is focused on adding missing Oracle functionality to Postgres, rather than helping in porting. For example, decode() was only added in Orafce 3.0beta because Postgres already has the CASE statement. Also, NVL is COALESCE: http://forums.devsh

Re: [Spacewalk-devel] PGPORT: Checking psql Success From Shell Script

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Jan 2009 02:18:51 +0530 Gurjeet Singh wrote: > Reading up on 'Exit Status' section in > http://www.postgresql.org/docs/8.3/static/app-psql.html shows that it > will return 3 if ON_ERROR_STOP was set, and it was run using a script. > > So

Re: [Spacewalk-devel] PGPORT: Checking psql Success From Shell Script

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Jan 2009 21:57:10 +0100 Jan Pazdziora wrote: > On Thu, Jan 29, 2009 at 04:01:40PM -0400, Devan Goodwin wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Working on the population of PostgreSQL schema in > > spacewalk-se

Re: [Spacewalk-devel] PGPORT: Checking psql Success From Shell Script

On Thu, Jan 29, 2009 at 04:01:40PM -0400, Devan Goodwin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Working on the population of PostgreSQL schema in > spacewalk-setup I landed in rhn-populate-database.pl, got the > script ready to populate pgsql schema as well but even if the > s

Re: [Spacewalk-devel] PGPORT: Checking psql Success From Shell Script

Reading up on 'Exit Status' section in http://www.postgresql.org/docs/8.3/static/app-psql.html shows that it will return 3 if ON_ERROR_STOP was set, and it was run using a script. So I guess you need to do it as: my $psql_cmd = "PGPASSWORD=" . $password . " psql -U " . $user . " -h " . $host . "

[Spacewalk-devel] PGPORT: Checking psql Success From Shell Script

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Working on the population of PostgreSQL schema in spacewalk-setup I landed in rhn-populate-database.pl, got the script ready to populate pgsql schema as well but even if the schema population fails miserably, the psql executable returns a 0 success cod

[Spacewalk-devel] PGPORT: PostgreSQL Schema Directory Layout Checked In

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Added a start on the PostgreSQL schema layout in the pgsql branch and some dummy tables/procedures. (will remove these as soon as there's *any* real schema in play) cd schema/spacewalk/postgresql/ psql -f main.sql -d spacewalk For the record I've bee

Re: [Spacewalk-devel] PGPORT: Early Schema Requests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Jan 2009 21:00:06 +0530 Gurjeet Singh wrote: > Can you post the exact error message you got? Not really an error so much as my code tries to call the procedure but I have no PostgreSQL schema or procedures yet. :) The ora2pg generated s

Re: [Spacewalk-devel] PGPORT: Early Schema Requests

Can you post the exact error message you got? >From the looks of it, I think following are the issues with it: 1) In Postgres we have to CREATE FUNCTION RETURNS VOID. 2) rhn_user_group_id_seq.nextval is being used, so we need to port that Sequence too. Will be doing this in about an hour from n

[Spacewalk-devel] PGPORT: Early Schema Requests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As mentioned in phone call this morning, a couple early requests for PostgreSQL schema + procs to be ported, I ran into a need for these in spacewalk-setup: Stored procedure: create_first_org.sql It delves out into a few tables, hopefully not far and

Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Jan 2009 09:48:42 -0500 "Jesus M. Rodriguez" wrote: > > > > - - spacewalk-setup will prompt if you'd like an "embedded" > > installation where we assume the admin doesn't know anything about > > databases, then just yum install postgresql

Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

On Tue, Jan 27, 2009 at 1:40 PM, Devan Goodwin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, 27 Jan 2009 22:55:03 +0530 > Gurjeet Singh wrote: > >> Thats good news. We will need more QA for the features provided by >> orafce. >> >> Can we have an optional pseudo package (so

Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

On Wed, Jan 28, 2009 at 7:47 AM, Jan Pazdziora wrote: > On Tue, Jan 27, 2009 at 02:40:56PM -0400, Devan Goodwin wrote: >> >> - - spacewalk-setup will prompt if you'd like an "embedded" installation >> where we assume the admin doesn't know anything about databases, then >> just yum install postgre

Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

On Tue, Jan 27, 2009 at 02:40:56PM -0400, Devan Goodwin wrote: > > - - spacewalk-setup will prompt if you'd like an "embedded" installation > where we assume the admin doesn't know anything about databases, then > just yum install postgresql and configure a database for them during > the setup aut

[Spacewalk-devel] PGPORT: How to Use What's In the "pgsql" Branch

Posted some notes on how you can actually use the pg modified code in the "pgsql" git branch. This isn't particularly useful yet as the setup process breaks midway (EnterpriseDB guys you probably want to avoid this for now as it will muck with the stability of your Spacewalk servers), but if you're

Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 27 Jan 2009 22:55:03 +0530 Gurjeet Singh wrote: > Thats good news. We will need more QA for the features provided by > orafce. > > Can we have an optional pseudo package (something like > spacewalk_postgres ) that spacewalk package would dep

Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

Thats good news. We will need more QA for the features provided by orafce. Can we have an optional pseudo package (something like spacewalk_postgres ) that spacewalk package would depend on, so that we make postgres and orafce part of those and 'yum install spacewalk_postgres' will automatically i

Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

Great! Bruce Momjian wrote: I tested Orafce 2.1.4 on Postgres 8.1 and found, aside from a few regression test alignment differences, it works fine, so I think we can move forward and use it. I am sure it will work fine on PG >= 8.2 as well. ___ Spa

[Spacewalk-devel] PGPORT: Orafce on Postgres 8.1

I tested Orafce 2.1.4 on Postgres 8.1 and found, aside from a few regression test alignment differences, it works fine, so I think we can move forward and use it. I am sure it will work fine on PG >= 8.2 as well. -- Bruce Momjian http://momjian.us EnterpriseDB

[Spacewalk-devel] PGPORT: Worklog Up, Master Merged, Scp Sync Script Coming Soon

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We've added a "worklog" to the wiki meant to identify the problems we've hit in pgsql branch and the porting effort and details on how we've solved them. We're hoping others can review this and spot any problems or situations we may not have thought of

[Spacewalk-devel] PGPORT Follow-up: Initial porting guidelines.

.) Orafce support for Postgres 8.1: I am unable to find any concrete documentation on Orafce, apart from the README in the sources. So can't comment on the deficiencies it'd have if ported to PG 8.1. .) Empty string in queries. ('') The proposed solution of putting a CHECK constraint wil

  1   2   >