Alvaro Herrera wrote:
Huh, isn't the test backwards?
In which way? I use a simple one but whatever test that uses 'exec sql
include foo' and foo.h doesn't exist, it will crash.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
Euler Taveira de Oliveira wrote:
> Hi,
>
> I found another bug when using 'exec sql include filename'. If you use a
> filename that doesn't exist, ecpg crashes while trying to close a null
> pointer. The above test case shows it. A possible fix is attached.
Huh, isn't the test backwards?
> --
Hi,
I found another bug when using 'exec sql include filename'. If you use a
filename that doesn't exist, ecpg crashes while trying to close a null
pointer. The above test case shows it. A possible fix is attached.
#include
/* foo.h doesn't exist */
exec sql include foo;
int main(void)
{
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Apparently the reason for pg_dump.c to need htup.h is getAttrName which
> needs system columns' attribute numbers. Of course, the first thing
> that comes to mind is that we should fix pg_dump to not require that
> header in the first place. Perhaps we
Tom Lane wrote:
> +1 for moving fastgetattr, heap_getattr, and the heaptuple.c functions
> to htup.h. I don't see any big gain from relocating the other stuff;
> it seems to largely all use about the same set of typedefs.
Ultimately that was my conclusion too. I tried moving the heaptuple.c
fun
Euler Taveira de Oliveira wrote:
This is a second try.
I forgot to say that this patch doesn't include nls support to ecpg
files automagically. If you guys think that it's is a Good Thing to do,
we need to hack the preproc.y to hardcode the locale stuff; if you
decide that it isn't necessar
On Sat, May 10, 2008 at 11:55:29AM -0400, Tom Lane wrote:
> IMHO a utility command should do one easily-explained thing. The fewer
> options the better.
Sticking to that principle makes for a better-maintained system. I
agree. If we want to point out, "You might rename your index
afterwards to
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
> If the user doesn't specify CONSTRAINT constraint_name, it will
> default to current implicit behavior of col_pkey.
IOW, the default behavior is to rename the index? Doesn
Jonah H. Harris wrote:
Yes, I just think PREBUILT conveys the meaning of the command more
appropriately. I could care less though.
(Please don't top-answer)
I don't think we should add new keywords unnecessarily.
cheers
andrew
On Sat, May 10, 2008 at 5:35 PM, Gregory Stark <[EMAIL P
Yes, I just think PREBUILT conveys the meaning of the command more
appropriately. I could care less though.
On Sat, May 10, 2008 at 5:35 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
>
>> So, would anyone be averse to something like the following:
>>
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> So, would anyone be averse to something like the following:
>
> ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
>
> If the user doesn't specify CONSTRAINT constraint_name, it will
> default to current implicit behavior of c
Peter Eisentraut wrote:
I suggest you keep working on this, and we will reconsider a more complete
patch at a later date.
This is a second try. Fix some issues pointed by Peter. It's a little
fatter 'cause I worked on almost all of the strings. I attempted to
mimic the postgresql style but I
So, would anyone be averse to something like the following:
ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame
If the user doesn't specify CONSTRAINT constraint_name, it will
default to current implicit behavior of col_pkey.
-Jonah
On Sat, May 10, 2008 at 1:08 PM, Joshu
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The one that makes a bit more sense is a new syncscan.h. And there are
> a lot of things in heapam.h that actually correspond to tuple
> manipulation (heap_form_tuple and so on), so perhaps a new header file
> would be appropriate, but there's already h
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>
>> Others are more conflictive. For example syncscan.c is keeping the
>> prototypes for its own functions on heapam.h. Also pruneheap.c and
>> rewriteheap.c. As a result, not only themselves need to include
>> heapam.h (without any other need fo
On Sat, May 10, 2008 at 10:55:57AM +0100, Gregory Stark wrote:
> "Zdenek Kotala" <[EMAIL PROTECTED]> writes:
> > Gregory Stark napsal(a):
> >> "Josh Berkus" <[EMAIL PROTECTED]> writes:
> >>
> >>> How about hacking together a simple patch tracker instead, as
> >>> Bruce suggested? I've never found
I promise I won't expend any real effort on this until after the
commitfest is over, but ...
While working on the recently committed constraints patch, I got annoyed
by the way in which DROP CASCADE frequently emitted "noise" messages.
For instance:
regression=# create table p1 (f1 int);
CREATE T
Tom Lane wrote:
Apparently your definition of "easy" depends entirely on
keystrokes and not at all on memory/cognitive burden.
I was trying to remove one opportunity for human error, which is tied to
memory and cognitive burden. It is very easy to fat finger something. Is
it a critical error
Stephen Frost wrote:
(BTW, why does your MUA set Mail-Followup-To: (and do it badly, what's
more) ?)
I'm amazed at the number of people who ask me this.. Guess it's just
different for different communities. Basically, I like to keep my mail
in the different folders it belongs in, s
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> As a counter point, I don't see any reason to make the DBA's life
> harder. Sure it is just one step but it is a human step, prone to error
> and taking more time than it should. Why not just make it easy?
I don't see that decorating infrequently-
Joshua D. Drake wrote:
Tom Lane wrote:
Well it should be optional but it would be nice if we had the option
to have it renamed per the default... meaning the same output if I
were to do this:
If you want that, you can rename the index (either before or
afterwards).
I don't see any reason
Tom Lane wrote:
Well it should be optional but it would be nice if we had the option to
have it renamed per the default... meaning the same output if I were to
do this:
If you want that, you can rename the index (either before or afterwards).
I don't see any reason to clutter the make-constra
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why, and exactly what would you define as "appropriate naming style"?
>> The user has always been free to pick whatever constraint name he
>> wants.
> Well it should be optional but it would be nice if we had the option to
> have
Alvaro Herrera napsal(a):
Others are more conflictive. For example syncscan.c is keeping the
prototypes for its own functions on heapam.h. Also pruneheap.c and
rewriteheap.c. As a result, not only themselves need to include
heapam.h (without any other need for it), but they force some other
f
Gregory Stark napsal(a):
"Zdenek Kotala" <[EMAIL PROTECTED]> writes:
Gregory Stark napsal(a):
"Josh Berkus" <[EMAIL PROTECTED]> writes:
How about hacking together a simple patch tracker instead, as Bruce
suggested? I've never found e-mail to be a particularly good way to track
patches.
T
On Sat, 2008-05-10 at 15:57 +1000, Brendan Jurd wrote:
> On Sat, May 10, 2008 at 2:49 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I see that Brendan has proposed the following definition on
> > CommitFest:Help:
> I wouldn't say I did anything so formal as proposing a definition =)
>
> Someone men
"Stephen Frost" <[EMAIL PROTECTED]> writes:
> I'd rather get responses to my emails through the list than directly to me.
> Additionally, I don't really need to get two copies of every email sent to
> me on a mailing list.
Then doesn't setting it to:
Andrew Dunstan <[EMAIL PROTECTED]>,PostgreS
"Zdenek Kotala" <[EMAIL PROTECTED]> writes:
> Gregory Stark napsal(a):
>> "Josh Berkus" <[EMAIL PROTECTED]> writes:
>>
>>> How about hacking together a simple patch tracker instead, as Bruce
>>> suggested? I've never found e-mail to be a particularly good way to track
>>> patches.
>>
>> The thi
On Sat, May 10, 2008 at 12:14:57AM -0300, Euler Taveira de Oliveira wrote:
> While i'm working on a ecpg patch I found a bug in ecpg code. The simple
> program above could reproduce it. But basically it crashes (segfault)
> because it's trying to use a inexistent connection when we're preparing
Gregory Stark napsal(a):
"Josh Berkus" <[EMAIL PROTECTED]> writes:
How about hacking together a simple patch tracker instead, as Bruce suggested?
I've never found e-mail to be a particularly good way to track patches.
The thing is that we don't just want to "track" patches. We want to talk
30 matches
Mail list logo
