Joe Abbate writes:
> 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
Hello Tom,
On 30/08/12 13:23, Tom Lane wrote:
> Joe Abbate 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 outpu
Joe Abbate writes:
> On 30/08/12 12:27, Tom Lane wrote:
>> The reason for the difference is that in 9.2 there's more than one
>> pg_catalog.upper():
> 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*
Hello Tom,
On 30/08/12 12:27, Tom Lane wrote:
> The reason for the difference is that in 9.2 there's more than one
> pg_catalog.upper():
>
> regression=# \df upper
> List of functions
>Schema | Name | Result data type | Argument data types | Type
>
Joe Abbate writes:
> Hello hackers,
> I've been testing Pyrseas against 9.2rc1. A test that does a CREATE
> OPERATOR is giving a small difference. Specifically, the test issues
> the statement:
> CREATE OPERATOR + (PROCEDURE = upper, RIGHTARG = text);
> Pyrseas then queries the pg_operator cat
Hello hackers,
I've been testing Pyrseas against 9.2rc1. A test that does a CREATE
OPERATOR is giving a small difference. Specifically, the test issues
the statement:
CREATE OPERATOR + (PROCEDURE = upper, RIGHTARG = text);
Pyrseas then queries the pg_operator catalog to map the procedure for
o
