On Thu, Jun 12, 2008 at 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> So that's leading me to lean towards keeping RemoveRelation
> et al where they are and distributing the work currently done in
> ProcessUtility out to them. This sounds duplicative, but about all that
> really is there to dupli
Hi,
Attached is a small patch to fix some typos in probes.d path.
--
Euler Taveira de Oliveira
http://www.timbira.com/
Index: doc/src/sgml/monitoring.sgml
===
RCS file: /a/pgsql/dev/anoncvs/pgsql/doc/src/sgml/monitoring.sgml,v
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Attached patch puts the "metadata" about a function, especially the
>> language name, at the top of the CREATE FUNCTION statement, above the
>> possibly long, multi-line function definition.
> Why the random switching between newline-before
On Thu, Jun 12, 2008 at 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Yep, I thought about doing the reverse. Namely Just passing the
>> DropStmt to RemoveRelation(s). But then all the permission check
>> functions are in utility.c. Splitting those
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Yep, I thought about doing the reverse. Namely Just passing the
> DropStmt to RemoveRelation(s). But then all the permission check
> functions are in utility.c. Splitting those out seemed to be about
> the same as splitting out all the ObjectAddress
On Thu, Jun 12, 2008 at 11:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I don't really like the patch though; it seems kind of a brute force
> solution. You've got ProcessUtility iterating through a list of objects
> and doing a little bit of work on each one, and then making a new list
> that Rem
On Thu, Jun 12, 2008 at 12:33:57PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Mon, Jun 09, 2008 at 05:56:59PM -0700, Neil Conway wrote:
> >> I'm not necessarily opposed to this, but I wonder if we really need
> >> *more* syntax variants for declaring set-returning func
On Thu, 2008-06-12 at 12:05 -0700, David Fetter wrote:
> On Thu, Jun 12, 2008 at 12:33:57PM -0400, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > On Mon, Jun 09, 2008 at 05:56:59PM -0700, Neil Conway wrote:
> I went and got reports from the field. Over the years, I've had to
On Thu, Jun 12, 2008 at 12:33:57PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Mon, Jun 09, 2008 at 05:56:59PM -0700, Neil Conway wrote:
> >> I'm not necessarily opposed to this, but I wonder if we really
> >> need *more* syntax variants for declaring set-returning
> >>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alex Hunsaker escribió:
>> I'm not proposing this patch for actual submission, more of a would this
>> work?
>> If I'm not missing something glaring obvious Ill go ahead and make the
>> rest of the Remove things behave the same way
> I don't think ther
On Thu, Jun 12, 2008 at 11:35 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> I don't think there's anything wrong with that in principle. However,
> does your patch actually work? The changes in expected/ is unexpected,
> I think.
Yeah I thought they looked a bit odd at first to. I thought it w
Alex Hunsaker escribió:
> Ok I'm obviously missing something important... Why not Just make the
> various Remove* functions take a list?
>
> I'm not proposing this patch for actual submission, more of a would this work?
> If I'm not missing something glaring obvious Ill go ahead and make the
> re
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I propose the following patch which moves the struct definitions to a
> separate new header relscan_internal.h.
This seems a little bizarre, seeing that there is almost nothing in
relscan.h except those structs.
Perhaps a better idea would be to put th
Hi,
relscan.h is very widely used -- in particular it is included by some
headers that want the IndexScanDesc and HeapScanDesc definitions in
prototypes. However, most of the time they are just passing the struct
through; they don't need to see the actual Heap/IndexScanDescData
definitions.
I pr
David Fetter <[EMAIL PROTECTED]> writes:
> On Mon, Jun 09, 2008 at 05:56:59PM -0700, Neil Conway wrote:
>> I'm not necessarily opposed to this, but I wonder if we really need
>> *more* syntax variants for declaring set-returning functions. The
>> existing patchwork of features is confusing enough a
On Mon, Jun 09, 2008 at 05:56:59PM -0700, Neil Conway wrote:
> On Tue, 2008-06-03 at 13:03 +0200, Pavel Stehule wrote:
> > this patch add support of table functions syntax like ANSI SQL
> > 2003.
>
> I'm not necessarily opposed to this, but I wonder if we really need
> *more* syntax variants for d
Greg Sabino Mullane <[EMAIL PROTECTED]> writes:
> Attached patch puts the "metadata" about a function, especially the
> language name, at the top of the CREATE FUNCTION statement, above the
> possibly long, multi-line function definition.
Why the random switching between newline-before and newline
Attached patch puts the "metadata" about a function, especially the
language name, at the top of the CREATE FUNCTION statement, above the
possibly long, multi-line function definition.
--
Greg Sabino Mullane
Index: pg_dump.c
===
RCS
On Wed, Jun 11, 2008 at 4:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Agreed --- I committed what I had, anyone want to volunteer for
> refactoring the execution of DropStmt?
Sure! see the attached patch...
> After looking again, I think that this is not technically very
> difficult, but coming
19 matches
Mail list logo
