comp.lang.ada
 help / color / mirror / Atom feed
* GNATColl and support for PostgreSQL stored procedures and non-public schemas
@ 2011-11-03 19:34 Thomas Løcke
  2011-11-04  8:36 ` Emmanuel Briot
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Løcke @ 2011-11-03 19:34 UTC (permalink / raw)


Hey,

Are there any plans for adding support for non-public schemas to the
gnatcoll_db2ada tool? Right now we have to resort to embedded SQL
instead of using the excellent GNATCOLL.SQL Ada style SQL interface.

Would it perhaps be possible to use the textual description method
found here:

     http://goo.gl/8ORh4

And if yes, then how?

And how about stored procedures? We use those A LOT in our application
but we haven't been able to figure out how to make use of them without
having to go back to plain old embedded SQL, which of course is sub-
optimal.

Any and all hints are more than welcome!

:o)

-- 
Thomas L�cke

Email: tl at ada-dk.org
Web: http//:ada-dk.org
http://identi.ca/thomaslocke



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: GNATColl and support for PostgreSQL stored procedures and non-public schemas
  2011-11-03 19:34 GNATColl and support for PostgreSQL stored procedures and non-public schemas Thomas Løcke
@ 2011-11-04  8:36 ` Emmanuel Briot
  0 siblings, 0 replies; 2+ messages in thread
From: Emmanuel Briot @ 2011-11-04  8:36 UTC (permalink / raw)


> Are there any plans for adding support for non-public schemas to the
> gnatcoll_db2ada tool? Right now we have to resort to embedded SQL
> instead of using the excellent GNATCOLL.SQL Ada style SQL interface.

No such plan at this stage. Presumably, adding those should not be too
difficult:
in the text file, the name of the tables would be "schema.name". At
this point, gnatcoll_db2ada
needs to issue a "CREATE SCHEMA schema" command. The second part of it
is to replace "." by
some other substring for the Ada identifiers that are generated to
represent the table.

> And how about stored procedures? We use those A LOT in our application
> but we haven't been able to figure out how to make use of them without
> having to go back to plain old embedded SQL, which of course is sub-
> optimal.

For aggregate functions, you can simply define new constants similar
to
GNATCOLL.SQL.Func_Count. For other types of stored procedures, you
could
copy the implementation of GNATCOLL.SQL.Lower, for instance, and
perhaps
even make it more general so that it takes the name of the procedure
in
parameter.

Emmanuel



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-11-04  9:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-03 19:34 GNATColl and support for PostgreSQL stored procedures and non-public schemas Thomas Løcke
2011-11-04  8:36 ` Emmanuel Briot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox