From: Peter Eisentraut <peter_e@gmx.net>
To: Preston A. Elder <prez@neuromancy.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Portable interfaces ...
Date: Fri, 26 Mar 2004 11:22:43 +0100
Message-ID: <200403261122.43740.peter_e@gmx.net> (raw)
In-Reply-To: <1080020317.10179.71.camel@temple.srealm.net.au>
References: <1080012121.10179.56.camel@temple.srealm.net.au>
<15657.1080018332@sss.pgh.pa.us>
<1080020317.10179.71.camel@temple.srealm.net.au>
Preston A. Elder wrote:
> Does postgres have an API review team or anything?
No.
> 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.
http://www.postgresql.org/docs/7.4/static/information-schema.html> Add to this the "support" for unicode - I mean, its almost like it
> was added as an afterthought,
Indeed.
> 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 don't understand what the API has to do with Unicode. Either your
strings are in Unicode or they are not. This is set by your
application.
> 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)
They should be.
> 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)).
The libpq API gives you a way to determine the binary length of a
returned datum. You need to allocate that dynamically.
> 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?
The plans are more or less that if you don't like it, try using a
different one, such as ODBC, or if a different programming language
than C.
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: peter_e@gmx.net, prez@neuromancy.net, tgl@sss.pgh.pa.us
Subject: Re: Portable interfaces ...
In-Reply-To: <200403261122.43740.peter_e@gmx.net>
* 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