On Wed, Sep 09, 2009 at 08:45:06PM -0400, Robert Haas wrote:
On Wed, Sep 9, 2009 at 6:24 PM, David Fetterda...@fetter.org wrote:
Anyhow, I think it's a bug and needs back-patching.
I suspect if it were as easy as removing the error test it would
have been done already. Perhaps you'd care
Folks,
CommitFest 2009-09 is now only days away! I have been having
discussions with a number of people, and the result of those
discussions is that I have agreed to manage the next CommitFest
insofar as patch assignment is concerned. Selena Deckelmann, Stephen
Frost, and Brendan Jurd have
Robert Haas wrote:
I wonder whether it would be appropriate to do something like
implement a method by which copy could return text[] and then one
could write wrappers around that functionality to do this as well as
other things.
It's not a function ... writing a copy() function
On Wed, Sep 9, 2009 at 10:40 PM, Andrew Dunstanand...@dunslane.net wrote:
Robert Haas wrote:
I wonder whether it would be appropriate to do something like
implement a method by which copy could return text[] and then one
could write wrappers around that functionality to do this as well as
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I wonder whether it would be appropriate to do something like
implement a method by which copy could return text[] and then one
could write wrappers around that functionality to do this as well as
other things.
Anything along
Robert Haas wrote:
However, I'm skeptical about whether the specific
thing you want to do after parsing (namely, drop excess columns,
null-fill missing ones) is sufficiently common to warrant a feature to
do only that. YMMV, of course.
So might my experience. I can tell you that I have
On Wed, Sep 9, 2009 at 11:01 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
I wonder whether it would be appropriate to do something like
implement a method by which copy could return text[] and then one
could write wrappers around that
Robert == Robert Haas robertmh...@gmail.com writes:
Just to pick up on some points from the discussion:
1. LATERAL has to be explicit because it changes the scope of
references. For example, in:
... (select ... FROM (select a AS b), (select b)) ...
the b in the second subselect
Tom Lane wrote:
What you're talking about is a
fairly specialized single-purpose feature, which nonetheless is going to
require a lot of infrastructure (for example, teaching psql's \copy
about it).
Well, that's hardly a lot.
Perhaps, for approximately the same amount of overhead,
we
Andrew Dunstan and...@dunslane.net writes:
you mean some sort of filter mechanism?
COPY FILTER function_name ( args) ... ?
That might work. Then we could provide a couple builtin and people could
write others in C or PL/dujour.
Yeah, that's pretty much what I was thinking, although
On Wed, Sep 09, 2009 at 09:13:40PM -0400, Robert Haas wrote:
Folks,
CommitFest 2009-09 is now only days away! I have been having
discussions with a number of people, and the result of those
discussions is that I have agreed to manage the next CommitFest
insofar as patch assignment is
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 9, 2009 at 11:01 PM, Tom Lanet...@sss.pgh.pa.us wrote:
The thought that comes to mind for me is something in front of copy,
that is, give it the text of each line and let it do a text-to-text
transformation before COPY chews on it.
That
On Wed, 2009-09-09 at 11:30 -0500, decibel wrote:
On Sep 9, 2009, at 8:05 AM, Peter Eisentraut wrote:
How is this better than just reading the information directly from
pg_depend?
pg_depend is very difficult to use. You have to really, really know
the catalogs to be able to figure it
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Could we
have a version of PQconnectdb() with an API more suited for setting the
params programmatically? The PQsetdbLogin() approach doesn't scale as
parameters are added/removed in future versions,
On Thu, 2009-09-10 at 00:31 +0200, Dimitri Fontaine wrote:
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Hannu Krosing ha...@2ndquadrant.com writes:
anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
the number in parentheses
Yeah, that idea occurred to me too. The
PGconn *PQconnectParams(const char **params)
Where params is an array with an even number of parameters, forming
key/value pairs. Usage example:
Maybe use the term properties (props for short) or options instead of params?
Params is already in heavy use. How about PQconnectProps(...) or
101 - 116 of 116 matches
Mail list logo
