Names that suddenly include an OID

There's been a very recent change to include the OID in certain names
in the system table. Do a "select * from pg_amop;" to see what I
mean: the values for amopselect and amopnpages didn't have the OID
appended before. Was this change intentional? If so, I'm really
curious as to why... And what's the best way to find out, from SQL,
that 'btreesel' should now be 'btreesel_1268'?

Yes, I don't like this change either. If the oid is needed it should be in a second field,
and the unique index should be ( name, theoid )

Andreas

There's been a very recent change to include the OID in certain names
in the system table. Do a "select * from pg_amop;" to see what I
mean: the values for amopselect and amopnpages didn't have the OID
appended before. Was this change intentional? If so, I'm really
curious as to why... And what's the best way to find out, from SQL,
that 'btreesel' should now be 'btreesel_1268'?

OK, it was me who added it, and it still has some problems. The reason
the oid was added is that the old code just displayed the
pg_proc.proname for regproc fields, and the input function just found
the FIRST function with a matching name, which is a problem because we
can have multiple functions with the same name but different types.

You can input into regproc with the name_oid format, or you can just
give it the oid.

The problem is that certain function create items now have problems, as
outlined in the e-mails I am attaching, and am still looking for
suggestions on this. I can put it back to the old way too.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

There's been a very recent change to include the OID in certain names
in the system table. Do a "select * from pg_amop;" to see what I
mean: the values for amopselect and amopnpages didn't have the OID
appended before. Was this change intentional? If so, I'm really
curious as to why... And what's the best way to find out, from SQL,
that 'btreesel' should now be 'btreesel_1268'?

Yes, I don't like this change either. If the oid is needed it should be in a second field,
and the unique index should be ( name, theoid )

Well, the problem is that it is a single column, so how to you pass two
values into a type? You really can't split a type across two columns.

Still looking for suggestions.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Bruce Momjian <maillist@candle.pha.pa.us> writes:

OK, it was me who added it, and it still has some problems. The
reason the oid was added is that the old code just displayed the
pg_proc.proname for regproc fields, and the input function just
found the FIRST function with a matching name, which is a problem
because we can have multiple functions with the same name but
different types.

Then the code in question should be changed to properly look for a
tuple where the name matches _and_ the types are right. Combining the
(overloaded) name and the (unique) OID into a text string seems very
inelegant to me, and intuitively very, very wrong: if names aren't
usable in a certain situation, use OIDs instead -- that's what they're
for -- but don't change the name to add (seemingly) random numbers to
make them unique.

Contrived, silly, irrelevant example to illuminate how I'm thinking:
if you used the string 'plus' to signify addition, and you decided you
had to differentiate between adding integers and adding floats, then

findfunc('plus');

should become

findfunc('plus', 'integer');

instead of forcing the programmer to write things like

findfunc('plus_234893');

or adding weird code to every use of 'plus' to look up what the silly,
composite name happens to be this time.

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

There's been a very recent change to include the OID in certain names
in the system table. Do a "select * from pg_amop;" to see what I
mean: the values for amopselect and amopnpages didn't have the OID
appended before. Was this change intentional? If so, I'm really
curious as to why... And what's the best way to find out, from SQL,
that 'btreesel' should now be 'btreesel_1268'?

I have just fixed this.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <maillist@candle.pha.pa.us> writes:

There's been a very recent change to include the OID in certain names
in the system table.

I have just fixed this.

Cool. Does this change require a new 'initdb'?

regards, tom lane

Bruce Momjian <maillist@candle.pha.pa.us> writes:

There's been a very recent change to include the OID in certain names
in the system table.

I have just fixed this.

Cool. Does this change require a new 'initdb'?

regards, tom lane

No. Internally they are the same.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026