Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Дата
Msg-id Pine.LNX.4.21.0003040427210.489-100000@localhost.localdomain
обсуждение исходный текст
Ответ на Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Список pgsql-hackers
Tom Lane writes:

> There's another issue, which is that the routines that implement
> operations for a particular type are generally named after the type's
> internal name.  I trust you are not going to propose that we find a way
> to put spaces into C function names ;-).  It seems to me that the
> confusion created by having support code named differently from the
> type's internal name is just as bad as having the internal name
> different from the external name.
> 
> This being the case, it seems like "bit_varying" might be a reasonable
> compromise for the internal name, and that should work already...

Okay, that's the first reasonable argument I've heard in this thread, and
I'll buy it. Since correspondence between internal type names and function
names *is* achievable without hacks we might as well go for this one.

In turn I'm thinking that it might be nice to have a backend function like
format_type(name[, int4]) that formats an internal type and any size
modifier for client consumption, like
format_type('varchar', 8)     => "CHARACTER VARYING(8)"format_type('my type')        => "\"my
type\""format_type('numeric',{xxx}) => "NUMERIC(9,2)"
 

That could put an end to keeping track of backend implementation details
in psql, pg_dump, and friends.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [GENERAL] Version 7.0 beta problem