Good day Guru
I thought on output to input relation in general.
Manual says about scalar types that input and output functions should be
inverse to each other, because of dump problems (if output function prints
a value not in a format that input function waiting for)
That's the geat problem i
[EMAIL PROTECTED] says...
> I suggest Joe Conway's "SQL for Smarties"
Surely that's Joe Celko?
> or "SQL Queries for Mere Mortals"
> from another author.
Michael J. Hernandez, John L. Viescas
Paul...
--
plinehan__AT__yahoo__DOT__com
C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.0
Bryan,
> I could be mistaken, but I'm pretty sure Josh means Joe Celko's "SQL for
> Smarties" as I've seen him mention it before, and not Joe Conway.
Ooops! yes, Joe Conway is a major PostgreSQL contributor and author of the
tablefunc /contrib library; Joe Celko wrote the book.
--
-Josh Berku
>I suggest Joe Conway's "SQL for Smarties" or "SQL Queries for Mere
Mortals"
>from another author.
I could be mistaken, but I'm pretty sure Josh means Joe Celko's "SQL for
Smarties" as I've seen him mention it before, and not Joe Conway.
-b
---(end of broadcast)---
Greg Stark <[EMAIL PROTECTED]> writes:
> This still suffers from one major deficiency. The order that objects are
> outputed isn't necessarily consistent between databases. If I add tables to
> the development server but then add them to the production server in a
> different order the schema still
Tom Lane <[EMAIL PROTECTED]> writes:
> Returning to the original problem, it seems to me that comparing "pg_dump
> -s" output is a reasonable way to proceed.
I've actually started checking in a pg_dump -s output file into my CVS tree.
However I prune a few key lines from it. I prune the TOC O
Jeff,
> UPDATE ordercharges INNER JOIN orders ON
> orders.orderid = ordercharges.orderid
> SET orderchargeasbilled =
You may only UPDATE one table at a time, you can't update a JOIN. So when
selecting from another table to filter or calculate your update, the form is:
UPDATE orderchanges
SET
Josh Berkus wrote:
Richard,
You might want to search the mailing list archives for discussion of an
oracle version of dblink - I seem to remember someone saying they were
working on such a thing.
Yes, it'll be out sometime after 7.4. According to their posts in Augu
On Wednesday 29 Oct 2003 2:58 pm, Stephan Szabo wrote:
> On Wed, 29 Oct 2003, Gary Stainburn wrote:
> > Hi folks,
> >
> > don't know if it's cos of the 17 hours I've just worked (sympathy vote
> > please) but I can't get this one worked out
> >
> > I've got table names with nid as name id field and
Thanks guys,
I had a feeling this was the case, but wasn't sure.
The one-version pg_dump looks like a winner.
Regards
Stefan
##START##
=> Rod Taylor <[EMAIL PROTECTED]> writes:
=> >> What I did next, is put a trigger on pg_attribute that should, in theory,
=> >> on insert and update, fire up a f
On Wed, 29 Oct 2003, Gary Stainburn wrote:
> Hi folks,
>
> don't know if it's cos of the 17 hours I've just worked (sympathy vote please)
> but I can't get this one worked out
>
> I've got table names with nid as name id field and nallowfollow flag.
> I've got a vehicles table with vowner pointing
I need to adapt this an update statement to a general
form that will iterate over multiple orderids for a given
customerinvoiceid. My first concern is a form that will
work for a given orderid, then an expanded version that
will work on all orderids with a specific
customerinvoiceid as a parameter.
Hi folks,
don't know if it's cos of the 17 hours I've just worked (sympathy vote please)
but I can't get this one worked out
I've got table names with nid as name id field and nallowfollow flag.
I've got a vehicles table with vowner pointing at nid and a vallowfollow
field.
How can I update na
Rod Taylor <[EMAIL PROTECTED]> writes:
>> What I did next, is put a trigger on pg_attribute that should, in theory,
>> on insert and update, fire up a function that will increment a version
> System tables do not use the same process for row insertion / updates as
> the rest of the system. You're
> What I did next, is put a trigger on pg_attribute that should, in theory,
> on insert and update, fire up a function that will increment a version
System tables do not use the same process for row insertion / updates as
the rest of the system. You're trigger will rarely be fired.
signature.asc
Correction on the function :
The function currently on the database did has
select int4(description) + 1 into v_new_version from pg_description
where objoid = NEW.attrelid;
in stead of
select int4(description) into v_new_version from pg_description
where objoid = NEW
Hi all,
I'm trying to create some kind of table version control
system for approximately 300 postgres databases
ranging in version from 7.1.2 to 7.3.4.
I compared the "pg_dump -s" output between
the various versions of databases, but the format is inconsistent,
and I can't do diff's to check th
17 matches
Mail list logo
