Alvaro Herrera wrote:
> Excerpts from Kevin Grittner's message:
> No strong opinion on this, really, but your strcpy should use a
> StringInfo buffer instead of the char[200]. That's going to bite
> someone.
Yeah, this was thrown together in a bit of a hurry because of
development deadlines h
Excerpts from Robert Haas's message of mié feb 23 17:03:23 -0300 2011:
> On Wed, Feb 23, 2011 at 2:48 PM, Alvaro Herrera
> wrote:
> > Is this intended for 9.1?
>
> Kevin already expressed his intention to add this to the first 9.2CF.
> It's far too late to BEGIN discussing new features for 9.1.
On Wed, Feb 23, 2011 at 2:48 PM, Alvaro Herrera
wrote:
> Is this intended for 9.1?
Kevin already expressed his intention to add this to the first 9.2CF.
It's far too late to BEGIN discussing new features for 9.1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
Excerpts from Kevin Grittner's message of mié feb 23 16:20:16 -0300 2011:
> Alvaro Herrera wrote:
>
> > Why not use quote_identifier and quote_literal_cstr instead of
> > this new strcpy thing?
>
> We've got various types of software that will be parsing these
> payloads, and it's a little eas
Alvaro Herrera wrote:
> Why not use quote_identifier and quote_literal_cstr instead of
> this new strcpy thing?
We've got various types of software that will be parsing these
payloads, and it's a little easier to parse if the quoting is
unconditional. If that's a barrier to acceptance we coul
Excerpts from Kevin Grittner's message of mié feb 23 13:43:19 -0300 2011:
> Alvaro Herrera wrote:
>
> > I think it'd be better to use RelationGetIndexList (which gets the
> > index list from relcache) and fetch the index tuples from
> > syscache; see relationHasPrimaryKey for sample code.
>
>
Alvaro Herrera wrote:
> I think it'd be better to use RelationGetIndexList (which gets the
> index list from relcache) and fetch the index tuples from
> syscache; see relationHasPrimaryKey for sample code.
Thanks. Patch done that way attached. Will get it into tomorrow's
system testing here.
Excerpts from Kevin Grittner's message of mar feb 22 20:29:26 -0300 2011:
> Andrew Dunstan wrote:
>
> > Have you performance tested it? Scanning pg_index for index
> > columns for each row strikes me as likely to be unpleasant.
>
> I haven't, yet. I had rather assumed that the index info for
Andrew Dunstan wrote:
> Have you performance tested it? Scanning pg_index for index
> columns for each row strikes me as likely to be unpleasant.
I haven't, yet. I had rather assumed that the index info for a
relation would have a high probability of being cached during
execution of an AFTER
