"Mike Mascari" <[EMAIL PROTECTED]> writes:
>> Does Oracle's PL/SQL have a concept of record variables? If so, what
>> do they do in this situation?
> In Oracle 8, a row of NULLs:
> 1 CREATE OR REPLACE FUNCTION foo(t IN NUMBER)
> 2 RETURN NUMBER
> 3 IS
> 4 emp_rec employees%ROWTYPE;
On Friday 10 January 2003 23:50, Marc G. Fournier wrote:
> That was the aspect I feared ... almost an argument in itself for why psql
> should be in gborg as a seperate project ;)
You've got to be kidding. The main command-line interface NEEDS to be part of
the main package. The solution is to
On Fri, 2003-01-10 at 22:14, Ashley Cambrell wrote:
> First problem though is that you have to know the sequence name that
> is autogenerated from the serial
... which is not a legitimate problem, IMHO.
> secondly, I thought that sequences worked outside of transactions
They do, but obviously no
On Fri, 2003-01-10 at 21:27, Christopher Kings-Lynne wrote:
> So what actually is the point of OIDs then?
My understanding is that they're used to uniquely identify entries in
system catalogs. If there's a good reason to make use of OIDs on user
tables, I can't see it...
Cheers,
Neil
--
Neil Co
> We clearly need to have a 7.3.2, but I was thinking late January would
> be about the right time frame. Bugs are still trickling in (eg, the
> plpgsql one Neil just identified), and so far we've not seen anything
> that would make me feel we need an immediate release ...
I'm biased, but I think
On Fri, 10 Jan 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Right. It is just the _cruft_ factor that has prevented us from doing
> > it in the past.
>
> We've never before attempted to make psql cope with back-version
> servers. It might be a good idea in future --- but
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Right. It is just the _cruft_ factor that has prevented us from doing
> it in the past.
We've never before attempted to make psql cope with back-version
servers. It might be a good idea in future --- but it strikes me
as a new feature (and not a trivia
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are we near needing 7.3.2?
We clearly need to have a 7.3.2, but I was thinking late January would
be about the right time frame. Bugs are still trickling in (eg, the
plpgsql one Neil just identified), and so far we've not seen anything
that would make m
Are we near needing 7.3.2? The contraint dump patch is post-7.3.1 too,
and Tom applied a big fix recently to 7.3.X.
---
Laurette Cisneros wrote:
> That did the trick...fixed pg_dump!
>
> And, pg_restore works on it too!
That did the trick...fixed pg_dump!
And, pg_restore works on it too!
Yay, I can go home now.
Thanks very much for your help!
On Fri, 10 Jan 2003, Tom Lane wrote:
> Laurette Cisneros <[EMAIL PROTECTED]> writes:
> > This does not:
> > pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
> > Segmen
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Fri, 2003-01-10 at 20:28, Tom Lane wrote:
> >> Clearly, RETURN NEXT with an undefined record variable shouldn't dump
> >> core, but what should it do? Raise an error, or perhaps be a
Neil Conway wrote:
On Fri, 2003-01-10 at 18:17, Ashley Cambrell wrote:
The problem with getting rid of OIDs as default is there is then no way
to get the primary key of a just inserted row with out OIDs (as far as I
know)
Use currval() on the PK sequence -- if you call i
> Right. It is just the _cruft_ factor that has prevented us from doing
> it in the past.
Well, you could always have the function library for each different
version in a different shared lib which you load on demand.
Alternatively, follow the phpPgAdmin3 style and have a class 'Postgres71'
and
So what actually is the point of OIDs then? If you set OIDs ff by default
and use currval, what's the point of having OIDs at all?
Chris
On 10 Jan 2003, Neil Conway wrote:
> On Fri, 2003-01-10 at 18:17, Ashley Cambrell wrote:
> > The problem with getting rid of OIDs as default is there is then
The real question is how tables are dumped from 7.3 and below. Does it
always explicitly specify 'WITH OIDS' for tables with OIDs?
If not, this would have little benefit for me I guess...
I still vote for the ability to drop OIDs from a table :)
Chris
On 10 Jan 2003, Neil Conway wrote:
> Folk
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2003-01-10 at 20:28, Tom Lane wrote:
>> Clearly, RETURN NEXT with an undefined record variable shouldn't dump
>> core, but what should it do? Raise an error, or perhaps be a no-op?
> I'd vote for making it a no-op. Raising an error is too severe fo
On Fri, 2003-01-10 at 20:28, Tom Lane wrote:
> The core dump appears to occur when the SELECT INTO fails to retrieve
> a row, leaving "finalrec" undefined.
Thanks very much for your help, Tom.
> Clearly, RETURN NEXT with an undefined record variable shouldn't dump
> core, but what should it do? R
Thanks.
I've nulled all the "comment on view"s but still get it...
On Fri, 10 Jan 2003, Tom Lane wrote:
> Laurette Cisneros <[EMAIL PROTECTED]> writes:
> > This does not:
> > pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
> > Segmentation fault (core dumped)
>
> If you have any comments on
Marc G. Fournier wrote:
> > > How hard would it be to add in a simple version check, like Robert Treat
> > > suggested? Where, when you type in \d, it uses a pre-v7.3 schema if
> > > attached to a pre-v7.3 server? With the changes that have gone in since
> > > v7.3.1, we're going to need to do a
On Fri, 10 Jan 2003, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Fri, 10 Jan 2003, Peter Eisentraut wrote:
> >
> > > Marc G. Fournier writes:
> > >
> > > > We've started to upgrade the client machines, before upgrading the server
> > > > itself, but it looks like the psql client isn't ba
Neil Conway <[EMAIL PROTECTED]> writes:
> Someone contacted me in IRC about a bug in PL/PgSQL. I've confirmed that
> the example SQL they sent me causes a segfault on my machine (CVS HEAD),
> but I've so far not had a lot of success tracking down the exact cause
> of the problem.
The core dump app
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> This does not:
> pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
> Segmentation fault (core dumped)
If you have any comments on views, this is probably an instance of a
known bug:
2002-12-27 12:10 tgl
* src/bin/pg_dump/: pg_dump.c (REL7_
Oh goodness it's even worse as pg_restore can't read the archive from the
first pg_dump:
pg_dump -h myhost -p 5432 -f mydb.pgdmp mydb
pg_restore -l mydb.pgdmp
pg_restore: [archiver] input file does not appear to be a valid archive
Thanks,
L.
On Fri, 10 Jan 2003, Laurette Cisneros wrote:
>
>
Folks,
Someone contacted me in IRC about a bug in PL/PgSQL. I've confirmed that
the example SQL they sent me causes a segfault on my machine (CVS HEAD),
but I've so far not had a lot of success tracking down the exact cause
of the problem.
Backtrace:
#0 0x403ed17a in compatible_tupdesc (td1=0x8
This works:
pg_dump -h myhost -p 5432 -f mydb.cpgdmp mydb
This does not:
pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb
Segmentation fault (core dumped)
Nor does this:
pg_dump -h myhost -p 5432 -Ft -f mydb.cpgdmp mydb
(but I need the -Fc badly as my dbs backup up to large files)
Here's a sta
Marc G. Fournier wrote:
> On Fri, 10 Jan 2003, Peter Eisentraut wrote:
>
> > Marc G. Fournier writes:
> >
> > > We've started to upgrade the client machines, before upgrading the server
> > > itself, but it looks like the psql client isn't backwards compatible?
> >
> > The meta-commands are not, b
On Fri, 2003-01-10 at 18:44, Tom Lane wrote:
> Are you intending that pg_dump will always attach either WITH OIDS or
> WITHOUT OIDS to its CREATE TABLE commands?
Now that I think about it, I'd think pg_dump should attach one or the
other to all CREATE TABLE commands, regardless of the GUC variable
On Fri, 10 Jan 2003, Peter Eisentraut wrote:
> Marc G. Fournier writes:
>
> > We've started to upgrade the client machines, before upgrading the server
> > itself, but it looks like the psql client isn't backwards compatible?
>
> The meta-commands are not, because they now need to be schema aware.
Neil Conway <[EMAIL PROTECTED]> writes:
> Is it a good idea for CREATE TABLE to default to WITHOUT OIDS, rather
> than WITH OIDS?
Are you intending that pg_dump will always attach either WITH OIDS or
WITHOUT OIDS to its CREATE TABLE commands?
If we do not do so, the behavior of a dump and reload
On Fri, 2003-01-10 at 18:17, Ashley Cambrell wrote:
> The problem with getting rid of OIDs as default is there is then no way
> to get the primary key of a just inserted row with out OIDs (as far as I
> know)
Use currval() on the PK sequence -- if you call it from within the query
that inserted a
Neil Conway wrote:
>Folks,
>
>Is it a good idea for CREATE TABLE to default to WITHOUT OIDS, rather
>than WITH OIDS? Naturally, this would (a) be some time in the future
>(7.5, perhaps) and (b) only apply to user tables.
>
>
>The main disadvantage I can see is just backward compatibility. In order
On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote:
> Ross J. Reedstrom writes:
>
> > I already posted a one-line patch to implement this, but it doesn't
> > seem to hve come through to the list. Here it is inline, instead of as
> > an attachment:
>
> We need this to work without re
Marc G. Fournier writes:
> We've started to upgrade the client machines, before upgrading the server
> itself, but it looks like the psql client isn't backwards compatible?
The meta-commands are not, because they now need to be schema aware.
--
Peter Eisentraut [EMAIL PROTECTED]
---
Ross J. Reedstrom writes:
> I already posted a one-line patch to implement this, but it doesn't
> seem to hve come through to the list. Here it is inline, instead of as
> an attachment:
We need this to work without readline as well. (Of course there won't be
any history, but it needs to compile.
Folks,
Is it a good idea for CREATE TABLE to default to WITHOUT OIDS, rather
than WITH OIDS? Naturally, this would (a) be some time in the future
(7.5, perhaps) and (b) only apply to user tables.
The two advantages I can see are:
(1) Makes the storage of most tables more efficient; while you *ca
On Fri, 2003-01-10 at 12:30, Marc G. Fournier wrote:
>
> Is there any way of fixing the following?
>
> 164_459_openacs=> \d
> ERROR: parser: parse error at or near "."
> 164_459_openacs=>
>
> We've started to upgrade the client machines, before upgrading the server
> itself, but it looks like t
Is there any way of fixing the following?
164_459_openacs=> \d
ERROR: parser: parse error at or near "."
164_459_openacs=>
We've started to upgrade the client machines, before upgrading the server
itself, but it looks like the psql client isn't backwards compatible?
--
37 matches
Mail list logo
