| 656 | */ |
| 657 | |
| 658 | bool |
| 659 | check_client_encoding(char **newval, void **extra, GucSource source) |
| 660 | { |
| 661 | int encoding; |
| 662 | const char *canonical_name; |
| 663 | |
| 664 | /* Look up the encoding by name */ |
| 665 | encoding = pg_valid_client_encoding(*newval); |
| 666 | if (encoding < 0) |
| 667 | return false; |
| 668 | |
| 669 | /* Get the canonical name (no aliases, uniform case) */ |
| 670 | canonical_name = pg_encoding_to_char(encoding); |
| 671 | |
| 672 | /* |
| 673 | * If we are not within a transaction then PrepareClientEncoding will not |
| 674 | * be able to look up the necessary conversion procs. If we are still |
| 675 | * starting up, it will return "OK" anyway, and InitializeClientEncoding |
| 676 | * will fix things once initialization is far enough along. After |
| 677 | * startup, we'll fail. This would only happen if someone tries to change |
| 678 | * client_encoding in postgresql.conf and then SIGHUP existing sessions. |
| 679 | * It seems like a bad idea for client_encoding to change that way anyhow, |
| 680 | * so we don't go out of our way to support it. |
| 681 | * |
| 682 | * Note: in the postmaster, or any other process that never calls |
| 683 | * InitializeClientEncoding, PrepareClientEncoding will always succeed, |
| 684 | * and so will SetClientEncoding; but they won't do anything, which is OK. |
| 685 | */ |
| 686 | if (PrepareClientEncoding(encoding) < 0) |
| 687 | { |
| 688 | if (IsTransactionState()) |
| 689 | { |
| 690 | /* Must be a genuine no-such-conversion problem */ |
| 691 | GUC_check_errcode(ERRCODE_FEATURE_NOT_SUPPORTED); |
| 692 | GUC_check_errdetail("Conversion between %s and %s is not supported.", |
| 693 | canonical_name, |
| 694 | GetDatabaseEncodingName()); |
| 695 | } |
| 696 | else |
| 697 | { |
| 698 | /* Provide a useful complaint */ |
| 699 | GUC_check_errdetail("Cannot change \"client_encoding\" now."); |
| 700 | } |
| 701 | return false; |
| 702 | } |
| 703 | |
| 704 | /* |
| 705 | * Replace the user-supplied string with the encoding's canonical name. |
| 706 | * This gets rid of aliases and case-folding variations. |
| 707 | * |
| 708 | * XXX Although canonicalizing seems like a good idea in the abstract, it |
| 709 | * breaks pre-9.1 JDBC drivers, which expect that if they send "UNICODE" |
| 710 | * as the client_encoding setting then it will read back the same way. As |
| 711 | * a workaround, don't replace the string if it's "UNICODE". Remove that |
| 712 | * hack when pre-9.1 JDBC drivers are no longer in use. |
| 713 | */ |
| 714 | if (strcmp(*newval, canonical_name) != 0 && |
| 715 | strcmp(*newval, "UNICODE") != 0) |
nothing calls this directly
no test coverage detected