Re: Selecting a constant question: A summary

Dan,

> Secondly, we
> believe that we should treat the customers the way that we want to be
> treated.
> I think that the PostgreSQL group has managed the first objective, but
> not the second.

I just read this whole thread, and I feel that the sort of comment above is
completely unjustified, and counterproductive to your goal of adding a
feature to PostgreSQL which will make your driver work better. You'll be a
lot more likely to persuade people in the community to work with you if
you're not trying to convince them to change the project culture at the same
time.

You are on the developer mailing list for an open, community-based open source
project and *not* a commercial company. Therefore we do not have "customers"
and your paradigm is wrong. The PostgreSQL developers *are* treating you
exactly has they expect to be treated; as a developer, meaning that you argue
things out and defend your desire for a change. If you read anybody else's
discussion on this list you'll see that's how everyone else interacts.

If anything you've gotten more than your fair share of attention ... 40+ posts
from 1/2 dozen senior developers in less than 48 hours!

If you would prefer a more formal customer-vendor relationship, then I suggest
that you sign up as a customer of EnterpriseDB, Red Hat, Sun, Command Prompt,
SRA etc. or similar.

Now, that aside:

> According to SQL/CLI and ODBC 3.5, we should bind the length of a
> character column.

This is a much better approach. Standards are always nice.

> But it would be very nice if the database could provide a good estimate
> for us so that PostgreSQL could work like all of the other database
> systems. Code full of kludges is harder to maintain.

Do you have any information about how binding works in other databases? A
clear roadmap would make it easier for eventual developer implementation, and
obviously this is a solved problem elsewhere.

> And so I hope that we can get off on a better foot this time. If the
> answer is "No, the priority for this sort of thing is low, and we do not
> consider it important for our customers."

Again, we don't have "customers". So your desire to implement a change in
behavior is dependant on:
1. Getting this list to agree on the specification;
2. Convincing an *individual* PostgreSQL developer or contributing company
that this issue is in their high priority interest to fix,
OR
Fixing it yourself and submitting the patch to PostgreSQL.org.

> Then we will have to work
> around it. Hopefully, at least, it will get put into a queue of future
> enhancements.

Getting it on the TODO list is a good first step. However, that doesn't get
it implemented until it becomes some other developer's problem as well.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco