Anyone care about type "filename" ?

I'm thinking of removing the datatype "filename", which is a fixed-size
array of 256 characters with no support functions other than input and
output converters. Apparently it was once used in the system tables,
but it is so no longer AFAICT. Since it's fixed-length, it cannot be
made TOASTable, which makes it substantially inferior to type "text"
for any purpose that I can think of.

Anyone using this type?

I vote for removal.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Mon, 31 Jul 2000, Bruce Momjian wrote:

I'm thinking of removing the datatype "filename", which is a fixed-size
array of 256 characters with no support functions other than input and
output converters. Apparently it was once used in the system tables,
but it is so no longer AFAICT. Since it's fixed-length, it cannot be
made TOASTable, which makes it substantially inferior to type "text"
for any purpose that I can think of.

Anyone using this type?

I vote for removal.

works for me too ...

curious though, but why would such a type even be used in the system
tables? what difference does it have to a varchar(256)?

The Hermit Hacker <scrappy@hub.org> writes:

curious though, but why would such a type even be used in the system
tables? what difference does it have to a varchar(256)?

It was *fixed* length, not varlena. 256 bytes, no more, no less,
no length word, no nuthin.

Might've had some use in a system table, but I can't see a reason
for it in general-purpose user tables.

In any case, it's already history ;-)

regards, tom lane

On Tue, 1 Aug 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

curious though, but why would such a type even be used in the system
tables? what difference does it have to a varchar(256)?

It was *fixed* length, not varlena. 256 bytes, no more, no less,
no length word, no nuthin.

okay, reword ... what would have been the difference between that and
char(256)? :) I'm just curious as to whether it had any checks that would
have validated it as being a filename or something like that, that's all
...

The Hermit Hacker <scrappy@hub.org> writes:

okay, reword ... what would have been the difference between that and
char(256)? :) I'm just curious as to whether it had any checks that would
have validated it as being a filename or something like that, that's all

Actually, the input converter did have some code to expand "~username"
paths. But putting that in the input converter was broken by design;
you don't want the home directory expanded in a path when it's stored
into the database, you want to expand it when the path is used (what
if the user's home dir has moved since you made the DB entry?)

It might be worth pulling that code out of the CVS attic and inventing
a text-to-text "expand_pathname()" function that expands ~username and
perhaps also $ENVIRONMENTVAR in text strings interpreted as pathnames.
But I doubt that having a separate type for filenames is useful.

regards, tom lane

On Tue, 1 Aug 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

okay, reword ... what would have been the difference between that and
char(256)? :) I'm just curious as to whether it had any checks that would
have validated it as being a filename or something like that, that's all

Actually, the input converter did have some code to expand "~username"
paths. But putting that in the input converter was broken by design;
you don't want the home directory expanded in a path when it's stored
into the database, you want to expand it when the path is used (what
if the user's home dir has moved since you made the DB entry?)

Ah, okay, cool ... thanks :) Just seemed like a weird type to define if
you don't do anything different then char(256) would have done ...