pg_conversion seems rather strangely defined

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: pg_conversion seems rather strangely defined
Date: 2016-01-05 18:46:51
Message-ID: 6198.1452019611@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

What is the point of pg_conversion.condefault (the flag that says whether
a conversion is "default")? AFAICS, there is absolutely no way to invoke
a conversion that is not default, which means we might as well eliminate
the concept.

I do not see a lot of point in the namespacing of encoding conversions
either. Does anyone really need or use search-path-dependent lookup of
conversions? (If they do, it's probably broken anyway, since for example
we do not trouble to re-identify the client encoding conversion functions
when search_path changes.)

While actually removing pg_conversion.connamespace might not be worth
the trouble, it's mighty tempting to have just a single unique index on
(conforencoding, contoencoding), thereby enforcing that There Can Be Only
One conversion between any given pair of encodings, and then we can just
use that index to find the right entry without any fooling with search
path.

But in any case we should get rid of the concept of defaultness, because
it's pointless; all entries should be equally "default".

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Korobeinikov 2016-01-05 19:03:30 Re: Beginner hacker item: Fix to_reg*() input type
Previous Message Tom Lane 2016-01-05 18:04:03 Re: Beginner hacker item: Fix to_reg*() input type