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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BIT/BIT VARYING names (was Re: [HACKERS] Beta for 4:30AST)
Date: 2000-03-04 17:06:37
Message-ID: Pine.LNX.4.21.0003040427210.489-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-03-04 17:06:43 Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
Previous Message Peter Eisentraut 2000-03-04 17:06:11 Re: [GENERAL] Version 7.0 beta problem