Hello Tom, On 30/08/12 13:23, Tom Lane wrote: > Joe Abbate <j...@freedomcircle.com> writes: >> Hmmm ... Well, I'm just doing the same thing as pg_dump, which in 9.2rc1 >> still outputs the same as before, namely: > > Well, evidently you're *not* doing the same thing as pg_dump.
I meant that the Pyrseas dbtoyaml's output is essentially the same as pg_dump, e.g., schema public: operator +(NONE, text): procedure: upper Therefore, if psql doesn't have problem restoring the operator from the pg_dump output, neither should yamltodb have problem generating the SQL to recreate the operator. The above YAML (with or without the schema qualification) does generate the correct SQL and pg_operator.oprcode ends up with the correct OID. So at least for this test case, dbtoyam/yamltodb is not broken (but I'll have to do something about the unittest difference). > What's physically in there is an OID (and so the casts above are no-ops > at the representational level). What we're discussing is the behavior > of the output function for the regproc or regprocedure types. Yes, I suspected that an OID was stored. What I'd still quibble with is the use of the ambiguous regproc in pg_operator (also pg_type) and the still-ambiguous schema-qualified proc name. I guess it's not feasible (at least, short term), but it'd be preferable to store a "raw" OID and let the user cast to regprocedure (or change the 'regproc' to 'regprocedure'). Best regards, Joe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers