Neil Conway <[EMAIL PROTECTED]> writes:
> As a result, ExecInitScanTupleSlot(), ExecInitResultTupleSlot(),
> ExecTypeFromTL(), and ExecCleanTypeFromTL() are now all trivial
> (1 line) functions. I could have replaced these with macros, but I
> didn't: does anyone thinks that would be worth doing?
This patch fixes a trivial compiler warning introduced recently in
bufmgr.c
-Neil
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.145
diff
Neil Conway <[EMAIL PROTECTED]> writes:
> This patch adds some primitive regression tests for the LISTEN,
> NOTIFY, and UNLISTEN commands -- there were previously no regression
> tests for this functionality.
These cannot usefully be tested with our current regression test
methodology, as you obse
Neil Conway <[EMAIL PROTECTED]> writes:
> This patch refactors CreateTupleDescCopy() and
> CreateTupleDescCopyConstr() to remove some duplicated code, and clean
> things up a little bit.
I think this is taking the "avoid duplicated code" mantra a little far.
You've defined a subroutine that return
Tom Lane <[EMAIL PROTECTED]> writes:
> I think this is taking the "avoid duplicated code" mantra a little
> far. You've defined a subroutine that returns a TupleDesc that is
> internally inconsistent and cannot usefully be used for anything
> until it's fixed by the parent routines.
Fair enough.
Neil Conway <[EMAIL PROTECTED]> writes:
> Now that I think about
> it, we could also just change the API to remove
> CreateTupleDescCopyConstr(), and replace it with an additional bool
> parameter to CreateTupleDescCopy().
That would be okay with me. It might be a good idea to change the name
com
Tom Lane <[EMAIL PROTECTED]> writes:
> That would be okay with me. It might be a good idea to change the
> name completely (perhaps CopyTupleDesc() ?) as a means of catching
> places that aren't correctly updated.
Done, and done -- a revised patch is attached.
-Neil
Index: src/backend/access/co
Tom Lane <[EMAIL PROTECTED]> writes:
> Please use names for the replacement routines that are more clear
> than "fooInternal". You can get away with that kind of name for a
> static function, but I think globally visible ones should have more
> meaningful names.
The only function I named "fooInte
There is an unused variable in an example function in the PL/PgSQL
documentation; this patch removes it.
-Neil
Index: doc/src/sgml/plpgsql.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.
Tom Lane <[EMAIL PROTECTED]> writes:
> We have previously speculated about setting up some sort of test
> harness program that can drive multiple backends through a
> coordinated series of operations.
It would also be useful to test other concurrent properties of the
backend: for example, "all int
Neil Conway <[EMAIL PROTECTED]> writes:
>> For ExecTypeFromTLInternal, maybe use ExecTupDescFromTL, which is a
>> more accurate name in the first place
> What's the logic in having ExecTypeFromTL() and ExecCleanTypeFromTL()
> implemented in terms of a function called ExecTupDescFromTL()? i.e. if
>
11 matches
Mail list logo