# `to_pinyin` (function)


- **Type:** FUNCTION
- **Returns:** `varchar(255)`
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `NAME` | `varchar(255)` |

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE FUNCTION `to_pinyin`'`._

## Narrative

**Business context:** Converts a Chinese string to its lower-case pinyin transliteration. Intended for building search-friendly pinyin keys for customer/product/material names (so a user typing `bjly` finds `北京立扬`). Relies on the `t_base_pinyin` lookup table that maps GBK code-points to pinyin syllables.

**What it does:** hex-encodes the input, walks the byte pairs. For each pair: if the high byte > 128 (CJK range) it computes a GBK code value and looks up the matching `pin_yin_` in `t_base_pinyin` using the `CODE_ ASC LIMIT 1` "first ≥ key" rule, appends it, advances 4 hex chars; otherwise treats the pair as an ASCII char and appends it directly. Returns the lower-cased pinyin string.

**Invocation:** Status: appears orphaned. No caller found in any channel (form-master, gdsmodule hooks, other routines with a `to_pinyin(` invocation, xly-src grep). Live pinyin generation in xly happens Java-side (`PinyinUtil`/`HanyuPinyinHelper`) — this SQL-side polyfill was likely written as a fallback that was never wired up. Same family as orphan `FUN_GET_to_pinyin` (session 4). Candidate for maintainer audit / deletion.