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 up
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
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-after
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
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 as it
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
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 the
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
rest of
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 would
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 there's
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
functions.
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 functions. The
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
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 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 out seemed
-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 and
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
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 duplicate
19 matches
Mail list logo
