On 08/22/2012 11:18 PM, dmp wrote:
> One way around this I found is send the data with the initial prepare
> statement creation.
... which is OK if you know what SQL injection is and you're really
careful, but not something that any user should ever be advised to do or
need to do.
> It looks like from your code the arrays you speak of are not
> java.sql.Array?
Correct, I'm asking whether PgJDBC should also accept native Java arrays
like String[] and convert them to java.sql.Array with appropriate type
inference its self.
It's correct to use java.sql.Array and Connection.createArrayFrom(...)
but it's evident that some in-the-wild code, including EclipseLink,
doesn't do that and expects the JDBC driver to accept raw arrays.
> John, the Silence I think is not purposeful.
I don't remember seeing the patch, actually.
http://www.postgresql.org/search/?m=1&q=John+Lister&l=19&d=365&s=d
The Pg mailing list manager is irritatingly good at eating messages with
attached patches, so it's possible nobody ever saw it.
> With the port to GIT does
> this not allow contributors to more easily process patches independently?
> I'm not that familiar with GIT so I apologize up front for my ignorance.
Pg is using a traditional patch-based workflow not a push-pull workflow,
so even if you do your work in public git branches you need to send
patches to get things merged, you can't just post a git ref or use a
GitHub pull request.
That doesn't mean it's useless to keep your work in git. I keep the few
patches I write for Pg in feature branches on my public GitHub account:
https://github.com/ringerc/pgjdbc
https://github.com/ringerc/postgres
primarily so I don't lose it, and I refer to the feature branch when I
post a patch, eg:
https://github.com/ringerc/postgres/tree/sequence_documentation_fixes
However, there'll never be a merge from my branch in the history, either
via a git merge commit or a fast-forward pull, because the changes enter
Pg via patches.
Of course, even if John did have the work in a git repo, the next
question would be "where and in which branch" ? You still need a way to
find the work. Is it on GitHub somewhere? In a branch of a user repo on
git.postgresql.org ? On some personal server that allows public
read-only git access? Without a URL git isn't any more help than a patch.
--
Craig Ringer