On Wed, Mar 17, 2004 at 11:02:38AM -0500, Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > The formatting function API can be pretty simple:
> > text *my_copy_format(text *attrdata, int direction,
> > int nattrs, int attr, oid attrtype, oid relation)
>
> This seems like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 17 March 2004 5:54 pm, Christopher Kings-Lynne wrote:
> > I was thinking of writing a cron job to update the CVS tree and then
> > build the documentation (takes about 10 minutes on my computer). Then
> > I could push it to wherever you li
I deal with this daily in a cygwin environment. I wrote a simple c++
program where I hardcoded the input file name/location and output file
name/location. I strip the quotation marks out where they are used for
identifying text fields and change the comma's used as CSV's to pipes.
I use a comb
That is why I suggested providing a pre-written/pre-compiled/installed
function for CSV (call it CSV?). Advanced users could still write
their own as people can write many other things if they know their ways.
As someone who just went through a whole truckload of crap getting
delimited file
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Attached are the test failures I'm currently getting.
It looks like Neil didn't update expected/float8-small-is-zero.out
for his recent changes (for which, shame on him). Would you get
together to verify the correct regression outputs for your
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> How come half the ALTER TABLE statements use relation_expr and half use
> qualified_name?
relation_expr allows specification of "foo *" and "ONLY foo", and is
appropriate for ALTER commands that can recurse to child tables.
qualified_name is a
Attached are the test failures I'm currently getting.
-bash-2.05b$ uname -a
FreeBSD mir.internal 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #0: Mon Sep
22 14:46:18 WST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MIR i386
Chris
parallel group (13 tests): text name char varchar oid boolean int2
How come half the ALTER TABLE statements use relation_expr and half use
qualified_name?
Is one more correct now?
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I was thinking of writing a cron job to update the CVS tree and then build
the documentation (takes about 10 minutes on my computer). Then I could
push it to wherever you like. Are we currently maintaining two or three
branches in the code? We may want to keep them seperate.
We could also maint
--On Dienstag, März 16, 2004 17:34:25 -0800 Jonathan Gardner
<[EMAIL PROTECTED]> wrote:
Would you like to work with incrementally updating materialized views? I
am currently deleting then reinserting rows that get updated with a
pretty stupid algorithm. If you would like to investigate incremen
Fabien COELHO <[EMAIL PROTECTED]> writes:
> There is something I cannot visualise about the idea being discussed.
What I'm imagining is a separate program that you run, and it connects
to the backend and grabs schema data much like pg_dump does. (In fact
the pg_dump code might possibly be useful
Dear Tom,
> I like the pg_advisor idea a lot better.
>
> [...]
>
> In the third place, if we try to solve the problem by embedding checks
> here and there in the backend, we'll limit ourselves to checks that can
> be made with minimal impact on backend performance and complexity. And
> we'll be
On Wednesday 17 March 2004 02:34 am, Neil Conway wrote:
>> Just a heads-up: list.c and pg_list.h will be reimplemented fairly
>> soon in CVS HEAD (the code isn't committed yet, but there's a
>> preliminary patch I can send you if you're interested).
BTW, where are you on that? I'm getting antsy t
On Wednesday 17 March 2004 17:36, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking of a GUC variable called PERFORMANCE_HINTS, which would
> > throw a message if a lookup from the primary to the foreign key didn't
> > have an index.
>
> I like the pg_advisor idea a lot
Silvio Mazzaro <[EMAIL PROTECTED]> writes:
> A made a tar backup copy of /var/lib/pgsql, but now (I'm still with Postgre
> 7.2 on a RedHat 7.3) restoring the data and launching the daemon i receive:
> postmaster successfully started
> bash-2.05$ FATAL 2: The database cluster was initialized with
On Wed, 17 Mar 2004, Jonathan Gardner wrote:
> I was thinking of writing a cron job to update the CVS tree and then
> build the documentation (takes about 10 minutes on my computer). Then I
> could push it to wherever you like. Are we currently maintaining two or
> three branches in the code? We m
Tom Lane <[EMAIL PROTECTED]> writes:
> BTW, something that just occurred to me now: EXPLAIN is currently really
> designed only for SELECTs. It would make sense to upgrade it for
> INSERT/UPDATE/DELETE to list the triggers that will get fired. While
> we'd have to treat user triggers as black bo
Hi all!
We've a problem...
A made a tar backup copy of /var/lib/pgsql, but now (I'm still with Postgre
7.2 on a RedHat 7.3) restoring the data and launching the daemon i receive:
postmaster successfully started
bash-2.05$ FATAL 2: The database cluster was initialized with
CATALOG_VERSION_NO 2
On Wednesday 17 March 2004 12:34 am, Dave Page wrote:
> > -Original Message-
> > From: Jonathan Gardner [mailto:[EMAIL PROTECTED]
> > Sent: 17 March 2004 01:41
> > To: [EMAIL PROTECTED]
> > Subject: [HACKERS] Doxygen?
> >
> > I'll start posting the documentation I am generating to my
> > va
I cc'ed the hackers list -- I hope you won't mind.
On Wednesday 17 March 2004 02:34 am, Neil Conway wrote:
> "Jonathan M. Gardner" <[EMAIL PROTECTED]> writes:
> > I formatted and added some documentation for List, FastList, and
> > Node. You can also browse to the list.c, pg_list.h, and nodes.h to
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Oh, why didn't you say so? Seems like the correct tool to solve that is
>> a partial unique index, not a constraint at all.
> Hmmm we support that?Darn, how do I miss these things. When did we
> start supporting it? Bric still has a lot of u
> > Also, because of the opposition by some DBA, these checks could be disable
> > by some options, but I would suggest the option to be on by default.
>
> I was thinking of a GUC variable called PERFORMANCE_HINTS, which would
> throw a message if a lookup from the primary to the foreign key didn'
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking of a GUC variable called PERFORMANCE_HINTS, which would
> throw a message if a lookup from the primary to the foreign key didn't
> have an index.
I like the pg_advisor idea a lot better.
In the first place, a lot of these sorts of checks
Tom,
> Oh, why didn't you say so? Seems like the correct tool to solve that is
> a partial unique index, not a constraint at all.
Hmmm we support that?Darn, how do I miss these things. When did we
start supporting it? Bric still has a lot of users who use 7.2.
--
-Josh Berkus
Ag
Josh Berkus <[EMAIL PROTECTED]> writes:
> BTW, the above is basically Bricolage's problem ... they
> want only active user names to be unique.
Oh, why didn't you say so? Seems like the correct tool to solve that is
a partial unique index, not a constraint at all.
regards
Fabien COELHO wrote:
>
> > > Or maybe some new "ADVICE" or "ODDITY" level next to "DEBUG NOTICE
> > > WARNING ERROR PANIC...", that would be hidden by default and triggered
> > > by an option?
> >
> > But that doesn't really solve the problem, which is that there are
> > conditions that it's diffi
Tom,
> AFAIR, whether a constraint is syntactically attached to a column or is
> "loose" in the table definition is not supposed to have any semantic
> consequences, but I might be wrong about that too.
Well, a table-level CHECK constraint can attach to more than one column, so in
that way *is*
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Where was it posted anyway?
>
> > Found it:
>
> >
> > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=200312010450.hB14ovH16330%40candle.pha.pa.us&rnum=8
>
> Thanks. The original patch is much olde
Tom,
> Is it? Our present handling of CHECK constraints cannot reasonably be
> thought to support anything but row-local constraints. If they're using
> a function to make an end-run around the check that prohibits subselects
> in CHECK constraints, then their problems are much more serious than
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Where was it posted anyway?
> Found it:
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=200312010450.hB14ovH16330%40candle.pha.pa.us&rnum=8
Thanks. The original patch is much older than I thought --- I was
looking
Tom Lane wrote:
Karel Zak <[EMAIL PROTECTED]> writes:
The formatting function API can be pretty simple:
text *my_copy_format(text *attrdata, int direction,
int nattrs, int attr, oid attrtype, oid relation)
This seems like it could only reasonably be implemented as a C function.
I ca
Karel Zak wrote:
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ ( column [, ...] ) ]
TO { 'fil
Karel Zak <[EMAIL PROTECTED]> writes:
> The formatting function API can be pretty simple:
> text *my_copy_format(text *attrdata, int direction,
> int nattrs, int attr, oid attrtype, oid relation)
This seems like it could only reasonably be implemented as a C function.
I can't reall
Hans-Jürgen Schönig wrote:
Karel Zak wrote:
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ (
Karel Zak wrote:
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ ( column [, ...] ) ]
T
Hi,
in TODO is item: "* Allow dump/load of CSV format". I don't think
it's clean idea. Why CSV and why not something other? :-)
A why not allow to users full control of the format by they own
function. It means something like:
COPY tablename [ ( column [, ...] ) ]
TO { 'filename' |
Folks, this is what greenhorns like me have been waiting for. Great stuff.
Keep the faith
Zoltan
- Original Message -
From: "Jonathan M. Gardner" <[EMAIL PROTECTED]>
To: "Bruce Momjian" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 7:50 AM
Subject: Re: [HAC
Tom Lane wrote:
Our present handling of CHECK constraints cannot reasonably be
thought to support anything but row-local constraints. If they're using
a function to make an end-run around the check that prohibits subselects
in CHECK constraints, then their problems are much more serious than
wh
> > Or maybe some new "ADVICE" or "ODDITY" level next to "DEBUG NOTICE
> > WARNING ERROR PANIC...", that would be hidden by default and triggered
> > by an option?
>
> But that doesn't really solve the problem, which is that there are
> conditions that it's difficult to test for on-the-fly while a
> -Original Message-
> From: Jonathan Gardner [mailto:[EMAIL PROTECTED]
> Sent: 17 March 2004 01:41
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Doxygen?
>
> I'll start posting the documentation I am generating to my
> vanity site (announcements later), but would this be
> something
40 matches
Mail list logo
