Re: Naming conventions for lots of stored procedures - Mailing list pgsql-general

On 3/10/2010 11:52 PM, Chris Travers wrote:
>
> There are two major limitations here of schemas:
>
> 1)  They can't be nested leading again to possible namespace ambiguity.
> 2)  there are a number of requests to try to get the application to
> install into an arbitrary, nonpublic schema.
>
> If schemas could be nested this would solve both of these problems.
>
> However, if the above is anywhere near a complete list of schemas for
> 1200 procedures, you must also have some strong naming conventions to
> prevent collisions.  I would be interested in what they are.
>
> Best wishes,
> Chris Travers
>

This is an app i took over and there was no strong name convention  plus
an godly  amount of overloaded procedures.

the procedures use very very long names  example
createardebitmemo(int, text, text date, numeric, text, int, int mint
date, int int, numeric )
createarcreditmemo(integer, text, text, date, numeric, text, integer,
integer, integer, date, integer, integer, numeric, integer, integer)

this means Create Accounts Receiver Debit Memo

deleteaccount(integer)
deleteaccountingperiod(integer)
deleteaccountingyearperiod(integer)
deletecustomer(integer)

after the moving the functions into schemas this is how one would/could
call them.
gl.deleteaccount(integer)
gl.deleteaccountingperiod(integer)
gl.deleteaccountingyearperiod(integer)
ar.deletecustomer(integer)
ar.createardebitmemo(int, text, text date, numeric, text, int, int mint
date, int int, numeric )
ar.createardreditmemo(integer, text, text, date, numeric, text, integer,
integer, integer, date, integer, integer, numeric, integer, integer)

Now one problem is if 2 functions have the same name, same number and
type of inputs then Postgresql will throw ambiguous error,  if the
search path includes the 2 schemas where  the functions are stored .

I wonder if any database out there allows for nesting schemas.  Which
i'm at a loss why nesting would help solve any problem what so ever.  I
imagine the search path on some connections would be all inclusive so
ambiguous names is not solved.   Also would not be a big fan typing
something like

AR.Customer.Editing.Delete(ID)

what has been gained???

think if the search path was all inclusive
  AR.Contact.Editing.Delete
WIP.WorkOrder.Delete

and this was called
Select Delete(5784);

Postgresql will through ambiguous error which delete, the one in
AR.Customer, AR.Contact or WIP.Workorder  schema.

All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by
ourproprietary quotation system. Quotations received via any other form of communication will not be honored. 

CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other
informationproprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it
addresses.If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified
thatany unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have
receivedthis e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this
e-mailimmediately. 
Thank you.