This sounds reasonable.  The current docs make it sound as if the aliases are going away very soon ... why?  It's a recent change.  In fact, old mysql aliases have been around since the 90's and afaik the mysql alias docs have only recently been removed.  It makes sense to encourage a move but not to scare people.

I vote +1 we create these alias entries because the move is so recent and will do so unless someone feels otherwise (then we can discuss it :)

I don't see problems with listing old functions in the manual. (create xml files that point to new functions)

I didn't create old function name xml files, since aliases aren't supposed to be documented. I'm not sure if it applies in this case.

If everyone agrees, please feel free to add entries.

It's been a long time since this all happened, we sorta missed the boat :)  Since it's been so long and search.php will indirectly redirect users to the proper places ... I think it's okay if we don't add all these aliases so am marking this as won't fix.  Note that the old names still work although they are deprecated.  They'll most likely work for quite awhile.

In the future we need to handle this more gracefully. The same approach that's applied to extensions (deletions and moves->pecl) can be applied here.

Should this be revisited? If we do this, we'll have to do it for every deprecated function in all of PHP >= 4.0.0. If done, we should do something like not show these aliases in the function lists/sidebar.

Looks like I'm one reason this never happenend, not sure how that happened exactly. I think we discussed this once.

I would be interested in a list of aliases, which would need documentation, so we can see, what impact would this have on the manual... Without this picture, it is hard to decide on what to do.

BTW when old function names become aliases of new names, then they are not "aliases" in terms of how people see them. So they don't fit the "we are not documenting aliases" rule.

http://www.php.net/pgsql lists 20 entries. IMHO too much to list on the sidebar... 

I'm closing this bug for a few reasons:

1) The "new" search mechanism works fine for this. For example going to php.net/pg_getlastoid (doing a function search) lists function names with the first being pg_getlast_oid.

2) This bug is so old.

3) The names are so close that someone looking for pg_getlastoid should assume pg_getlast_oid from the function list.

In the future we'll resolve this type of issue right away although I don't see this sort of problem ever coming up again unless done for core functions (like strlen->str_len).