Re: [HACKERS] [NOVICE] opr_charset rule in gram.y - Mailing list pgsql-hackers

From Neha Khatri
Subject Re: [HACKERS] [NOVICE] opr_charset rule in gram.y
Date
Msg-id CAFO0U+-0ue+4x7X_vyvntp=PNo1RmTCfeYJ4zADyAS4oaVCSSQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [NOVICE] opr_charset rule in gram.y  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] [NOVICE] opr_charset rule in gram.y  (Neha Khatri <nehakhatri5@gmail.com>)
List pgsql-hackers
On Tue, Mar 7, 2017 at 4:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Neha Khatri <nehakhatri5@gmail.com> writes:
> I was going through the grammer rule for Character types in gram.y and
> found an optional sub rule in is "opt_charset"

This question seems quite off-topic for pgsql-novice, so I've redirected
it to pgsql-hackers.
 
Thanks for appropriately categorizing. I was not sure.


> CharacterWithLength:  character '(' Iconst ')' opt_charset
> {
>             if (($5 != NULL) && (strcmp($5, "sql_text") != 0))
>                     $1 = psprintf("%s_%s", $1, $5);
>
>             $$ = SystemTypeName($1);

> I would like to understand how opt_charset would get used in real
> applications. I tried to make use of it but results in failure:

> postgres=# create table testchar (c1 char(5) character set utf8);
> ERROR:  type "pg_catalog.bpchar_utf8" does not exist
> LINE 1: create table testchar (c1 char(5) character set utf8);

> There does not seem to be any documentation available about this optional
> parameter in the documents for Character data type( at least I could not
> find any).

Some digging in the git history shows that opt_charset was introduced in
commit f10b63923 (in 1997!), and the current interpretation as
"typename_charsetname" appeared in commit 3e1beda2c.  Neither commit
adds any user documentation or even mentions fooling with character type
declarations in its commit message.  I think that this must have been
work-in-progress that Tom Lockhart left behind when he dropped out of
the project circa 2002.

Since there are no datatypes matching the "typename_charsetname" naming
pattern, and today we'd be unlikely to accept an implementation based on
that approach even if someone wrote one, my inclination is just to rip out
this code.  Maybe we could leave behind the no-op case that allows
"CHARACTER SET SQL_TEXT", but I don't really see the point, since we've
never documented supporting any such syntax.

Ok, understood, good historical detail.. Will go through "typename_charsetname"
to understand the concept. Then may be come up with the cleanup patch.

Thanks and Regards,
Neha

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE
Next
From: Mark Dilger
Date:
Subject: Re: [HACKERS] cast result of copyNode()