Thread: pg_dump and ANSI types (TODO item)
Just looking at the TODO list for other pg_dump related items, and saw: add pg_dump option to dump type names as standard ANSI types Tow questions: Do we already have a function to represent PG types as ANSI standard types? How should types that are not in the standard be represented? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Philip Warner writes: > Just looking at the TODO list for other pg_dump related items, and saw: > > add pg_dump option to dump type names as standard ANSI types > > Tow questions: > > Do we already have a function to represent PG types as ANSI standard types? format_type(pg_type.oid, pg_attribute.atttypmod) > How should types that are not in the standard be represented? Whatever format_type gives you. I wrote format_type for exactly this purpose a few weeks ago, but I figured I let you get the glory for making pg_dump use it. :-) psql uses it as well. Note: IMO it should not be an *option* to use format_type, it should always be used. It's nice for encapsulation on the programming side and there's no reason for using any other type names. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
At 23:59 4/08/00 +0200, Peter Eisentraut wrote: >> >> Do we already have a function to represent PG types as ANSI standard types? > >format_type(pg_type.oid, pg_attribute.atttypmod) Good; I thought that might be why you sent me the info... > >I wrote format_type for exactly this purpose a few weeks ago, but I >figured I let you get the glory for making pg_dump use it. :-) psql uses >it as well. > Is it in 7.0.2? >Note: IMO it should not be an *option* to use format_type, it should >always be used. It's nice for encapsulation on the programming side and >there's no reason for using any other type names. Sounds good to me, as long as we can be sure that the backend will undestand it's output...one reason for making it an option is was to allow ISO SQL exports for porting to other DBs when we know we have different formats (but no examples spring to mind). ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/