From: Preston A. Elder <prez@neuromancy.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Portable interfaces ...
Date: Tue, 23 Mar 2004 00:38:38 -0500
Message-ID: <1080020317.10179.71.camel@temple.srealm.net.au> (raw)
In-Reply-To: <15657.1080018332@sss.pgh.pa.us>
References: <1080012121.10179.56.camel@temple.srealm.net.au>
<15657.1080018332@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: prez@neuromancy.net, tgl@sss.pgh.pa.us
Subject: Re: Portable interfaces ...
In-Reply-To: <1080020317.10179.71.camel@temple.srealm.net.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox