On Wed, Sep 09, 2009 at 08:45:06PM -0400, Robert Haas wrote:
> On Wed, Sep 9, 2009 at 6:24 PM, David Fetter 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 to submit a
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 agree
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 returnin
On Wed, Sep 9, 2009 at 10:40 PM, Andrew Dunstan 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
>> other thing
Andrew Dunstan 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 these lines
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 Lane wrote:
> Andrew Dunstan 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 w
> "Robert" == Robert Haas 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 coul
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 coul
Andrew Dunstan 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 exactly where the
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 writes:
> On Wed, Sep 9, 2009 at 11:01 PM, Tom Lane 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 seems to me to be a whole lot l
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 figur
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas 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, but we could have
> something
On Thu, 2009-09-10 at 00:31 +0200, Dimitri Fontaine wrote:
> Hi,
>
> Tom Lane writes:
> > Hannu Krosing writes:
> >> anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
> >> the number in parentheses
> >
> > Yeah, that idea occurred to me too. The immediate practical problem
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
