Re: [HACKERS] Name type vs. char *

> We currently use Name sometimes, and char* other times to store
> relation, attribute, type, and view names.
>
> One thing Mariposa did was to make that more consistent, so you passed
> around Name(NameData pointers) instead of the more generic char *.
> However, the Name fields behave like char*, but are clearer.
>
> typedef struct nameData
> {
> char data[NAMEDATALEN];
> } NameData;
> typedef NameData *Name;
>
> Do people see value in making this switch? Would take me a few hours to
> make the change.

I have decided I don't even like this change. The confusion is because
of the on-disk name storage vs. query-supplied names. I will add this
to the developers FAQ. This has confused me, so I assume others may be
confused about the distinction.

Comments?

---------------------------------------------------------------------------

Why are table, column, type, function, view names sometimes referenced
as Name or NameData, and sometimes as char *?

Table, column, type, function, and view names are stored in system
tables in columns of type Name. Name is a fixed-length, null-terminated
type of NAMEDATALEN bytes. (The default value for NAMEDATALEN is 32
bytes.)

typedef struct nameData
{
char data[NAMEDATALEN];
} NameData;
typedef NameData *Name;

Table, column, type, function, and view names that come in to the
backend via user queries are stored as variable-length, null-terminated
character strings.

Many functions are called with both types of names, ie. heap_open().
Because the Name type is null-terminated, it is safe to pass it to a
function expecting a char *. Because there are many cases where on-disk
names(Name) are compared to user-supplied names(char *), there are many
cases where Name and char * are coerced to match each other.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)