Re: [HACKERS] [NOVICE] opr_charset rule in gram.y

[Neha Khatri]

I see it is already addressed in master. Thanks.

Regards,
Neha

Re: [HACKERS] [NOVICE] opr_charset rule in gram.y

[Neha Khatri]

On Tue, Mar 7, 2017 at 4:30 PM, Tom Lane  wrote:

> Neha Khatri  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

Re: [HACKERS] [NOVICE] opr_charset rule in gram.y

[Tom Lane]

Neha Khatri  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.

> 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.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers