From: | Joe Abbate <jma(at)freedomcircle(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_operator.oprcode in 9.2rc1 |
Date: | 2012-08-30 18:44:39 |
Message-ID: | 503FB497.9050903@freedomcircle.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom,
On 30/08/12 13:23, Tom Lane wrote:
> Joe Abbate <jma(at)freedomcircle(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-08-30 18:56:03 | Re: pg_operator.oprcode in 9.2rc1 |
Previous Message | Pavel Stehule | 2012-08-30 18:18:30 | Re: patch: shared session variables |