Subject: Re: Portable interfaces ...
From: "Preston A. Elder" <prez@neuromancy.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
In-Reply-To: <15657.1080018332@sss.pgh.pa.us>
References: <1080012121.10179.56.camel@temple.srealm.net.au>
	<15657.1080018332@sss.pgh.pa.us>
Content-Type: text/plain
Organization: Neuromancy Society
Message-Id: <1080020317.10179.71.camel@temple.srealm.net.au>
Mime-Version: 1.0
Date: Tue, 23 Mar 2004 00:38:38 -0500
Content-Transfer-Encoding: 7bit

On Tue, 2004-03-23 at 00:05, Tom Lane wrote:
> I don't have a comparably simple answer for your character encoding
> issue, but again I fear that relying on PG's internal facilities would
> be a bad idea for you.

Does postgres have an API review team or anything?

I mean, not trying to offend anyone here, but I don't see how any API
where you cannot find out details about a table and its columns (such as
character encoding schemes in effect, data type for the column (even if
only for pre-defined data types), field lengths (for strings/etc), etc)
could be considered anything but deficient.

Add to this the "support" for unicode - I mean, its almost like it was
added as an afterthought, since the API won't help you, without using
non-portable facilities (ie. headers/etc that may or may not exist on a
system).

I've programmed with other SQL databases before (specifically Microsoft
SQLServer and Oracle), both of which had standard API's for finding out
the exact kind of information that I speak of - and to be honest, I am
find it hard to believe I would be the first to request these kind of
things be made part of the standard API.

For now, I am (grudgingly) copying the OID codes, and going to use
system-based multibyte/unicode functions (and hope to heck that they are
compatible with postgres, but I get the feeling they are not fully
compatible after browsing pg_wchar.h) - and I'll be preying that I do
not need to find out any more information about a table or column that
would require me to use more 'server-side calls'.  As it is, right now,
I have no verification on things like string lengths because theres no
real way to find out the maximum length of a field (encoding-specific -
ie. for UTF-8, a length of 20 means 20 chars, for UTF-16, a length of 20
means 20 wchar_t's (40 bytes)).

If I sound accusatory in this email, I apologise - I'm just frustrated
(I am trying to write a library that will work on many different unix
variants, windows (compiled with BCB or MSVC) and on OSX - and these
kinds of things frustrate and complicate that process).  What are the
plans for the Postgres API - as I said, I find it hard to believe I am
the first to raise this issue, so are there plans to have function calls
to retrieve 'column properties' and the like?

-- 
PreZ
Founder
The Neuromancy Society
http://www.neuromancy.net