Ahh.. no wonder my aimless greps couldn't find anything.
I should just have read the BKI stuff ;)
Thanks
--
Rod
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Saturday, April 27, 2002 2:06 A
Rod Taylor wrote:
> Just exactly how does one get an array into a system table?
>
> Of course, _int2 and int2[] aren't normal C constructs so using it
> within CATALOG won't work.
>
> I suppose thats why the vector types were invented?
Well, pg_shadow had pg_class has:
relacl
Hi all,
I have a problem with metadata.just read this ...
Let us simply suppose a table "test" with 2 fileds "name (varchar(10))" and
"age (numeric)" and there b values as name="abc",age="20".
Now in a function i need to develop a list where the column header info has
to b made i
Just exactly how does one get an array into a system table?
Of course, _int2 and int2[] aren't normal C constructs so using it
within CATALOG won't work.
I suppose thats why the vector types were invented?
--
Rod
---(end of broadcast)---
TIP 4: D
At 11:50 25/04/02 -0400, Bruce Momjian wrote:
>Marc G. Fournier wrote:
> >
> > Just curious here, but has anyone taken the time to see how others are
> > doing this? For instance, if we go with 1, are going against how everyone
> > else handles it? IMHO, its not a popularity contest ...
Dec/RDB
At 11:49 AM 4/26/02 -0400, Tom Lane wrote:
>I'm still looking for an example of something that is (a) reasonable
>to set on a per-backend basis, and (b) not reasonable to roll back
>if it's set in a transaction that fails.
The way I see it is if (a) and you don't want it rolled back, you could pu
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > DB2 can run in two modes
> > 1) similar to ours, where logs are reused after checkpoints/commits
> > allow it.
> > 2) with log archiving: logs are never reused, but when system determines
> > it no longer needs them, it will hand sai
Marc G. Fournier wrote:
> > Second, there is the idea of doing #1, and having a GUC variable for #3.
> > Does anyone want that? I think Marc may. Anyone else?
>
> Actually, in light of Tom's comment about it not being the same syntax, I
> have to admit that I missed that syntax difference in th
> > The only problem with this is that I don't want the rename of a
> > constraint to have to fall over into the pg_depend table.
pg_depend
> > is currently happy with system OIDS or a Relation OID and some
unique
> > number to represent it -- much as pg_description wouldn't want to
know
> > the n
On Fri, 26 Apr 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > > Coz some things should not be rolled back. So you guys might come up with a
> > > different keyword for it.
> >
> > > CONFIG: for non transactional stuff that can appear as SQL statement
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> I was trying to say that _IF_ one ever needs to "SET" stuff that can't be
> rolled back then it may be better to use some other keyword for that feature.
> I'm actually for #1 SET being rolled back and to not have any "Oracle
> behaviour" settings at al
"Rod Taylor" <[EMAIL PROTECTED]> writes:
>> Could we instead insist on a unique name per-table, and make this
>> table's
>> key be (conrelid, conname)? Assigning a number seems quite
>> artificial.
> The only problem with this is that I don't want the rename of a
> constraint to have to fall ove
Bruce Momjian wrote:
> So you do see a difference between SET and DROP TABLE because the second
> is a utility command. OK, I'll buy that, but my point was different.
>
> My point was that we don't match Oracle for DROP TABLE, so why is
> matching for SET so important?
Good point, I never
At 10:34 AM 4/26/02 -0400, Tom Lane wrote:
>Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Coz some things should not be rolled back. So you guys might come up
> with a
> > different keyword for it.
>
> > CONFIG: for non transactional stuff that can appear as SQL statements.
> > SET: for stuff that
Jan Wieck <[EMAIL PROTECTED]> writes:
> SET does not. But Bruce said he doesn't see DROP TABLE beeing
> totally different. That is related to xmin/xmax, isn't it?
I think what Bruce meant was "if rollback is good for DROP TABLE,
why isn't it good for SET"?
rega
Shad <[EMAIL PROTECTED]> writes:
> I just recently upgraded from 7.0.x to 7.2.1.
You are clearly still talking to the 7.0 server:
> ERROR: OUTER JOIN is not yet supported
In general, psql's backslash commands tend to be version-specific,
and may fail when talking to a server of a different ver
> Could we instead insist on a unique name per-table, and make this
table's
> key be (conrelid, conname)? Assigning a number seems quite
artificial.
The only problem with this is that I don't want the rename of a
constraint to have to fall over into the pg_depend table. pg_depend
is currently h
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Hmmm...I don't see the need at all for NOT NULL constraint tracking. The
> spec doesn't seem to require it and we do not have names for them anyway.
> Even if they were given names, it'd be pointless, as there's only one per
> column.
Hmm,
Tom Lane wrote:
> Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Coz some things should not be rolled back. So you guys might come up with a
> > different keyword for it.
>
> > CONFIG: for non transactional stuff that can appear as SQL statements.
> > SET: for stuff that can be transactional.
>
>
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Marc G. Fournier wrote:
> > > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> > >
> > > >
> > > > Marc is suggesting we may want to match Oracle somehow.
> > > >
> > > > I just want to have our SET work on a sane manner.
> > >
> > > Myself, I wonder why Orac
Hannu Krosing <[EMAIL PROTECTED]> writes:
> DB2 can run in two modes
> 1) similar to ours, where logs are reused after checkpoints/commits
> allow it.
> 2) with log archiving: logs are never reused, but when system determines
> it no longer needs them, it will hand said log over to archiving proc
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Coz some things should not be rolled back. So you guys might come up with a
> different keyword for it.
> CONFIG: for non transactional stuff that can appear as SQL statements.
> SET: for stuff that can be transactional.
People keep suggesting this, an
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> For tracking of Foreign Keys, Check constraints, and maybe NULL / NOT
> NULL (specific type of check constraint) I intend to create (as per
> suggestion) pg_constraint.
> conrelid
> conname
> contype ('c'heck, 'f'oreign key, ???)
'u'unique, 'p'rimary ke
I have enabled the multibyte support by default. The default encoding
is SQL_ASCII. Note that I just modify configure minimu, and I will
remove unnecessary staffs including #ifdef MULTIBYTE step by step...
--
Tatsuo Ishii
---(end of broadcast)---
TI
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I have removed the --enable-syslog option. Now as far as the system
> > has syslog(), the syslog support code is always in the build.
> > If this seems ok, I will update the doc.
>
> Seems reasonable. It might be a good idea for configure to verify
Shad <[EMAIL PROTECTED]> writes:
> I just recently upgraded from 7.0.x to 7.2.1. I installed from
> postgresql-7.2.1-2PGDG.i386.rpm on a Linux Redhat 7.1 system. I was
> able to resolve most dependancies, except for it telling me that I
> needed libreadline.so.4, which " ldconfig -p|grep readli
Marc G. Fournier wrote:
> On Fri, 26 Apr 2002, Jan Wieck wrote:
>
> > Bruce Momjian wrote:
> > > Marc G. Fournier wrote:
> > > > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> > > >
> > > > >
> > > > > Marc is suggesting we may want to match Oracle somehow.
> > > > >
> > > > > I just want to have our
On Fri, 26 Apr 2002, Jan Wieck wrote:
> Bruce Momjian wrote:
> > Marc G. Fournier wrote:
> > > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> > >
> > > >
> > > > Marc is suggesting we may want to match Oracle somehow.
> > > >
> > > > I just want to have our SET work on a sane manner.
> > >
> > > Mys
Curt Sampson wrote:
> On Fri, 26 Apr 2002, Marc G. Fournier wrote:
>
> > NOTE that I *do* think that #1 is what *should* happen, but there should
> > be some way of turning off that behaviour so that we don't screw up ppl
> > expecting "Oracles behaviour" ...
>
> I don't think this follows. If it'
Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Thu, 25 Apr 2002, Bruce Momjian wrote:
> >
> > >
> > > Marc is suggesting we may want to match Oracle somehow.
> > >
> > > I just want to have our SET work on a sane manner.
> >
> > Myself, I wonder why Oracle went the route they went ... does
I just recently upgraded from 7.0.x to 7.2.1. I installed from
postgresql-7.2.1-2PGDG.i386.rpm on a Linux Redhat 7.1 system. I was
able to resolve most dependancies, except for it telling me that I
needed libreadline.so.4, which " ldconfig -p|grep readline" showed me I
already had, so forced a -
Bruce Momjian wrote:
>
> Curt Sampson wrote:
> > On Thu, 25 Apr 2002, mlw wrote:
> >
> > > ...but my gut tells me that using 16K blocks will increase performance
> > > over 8K. Aleady I have seen a sequential scan of a large table go from 20
> > > seconds using 8K to 17.3 seconds using 16K.
> >
>
> > For tracking of Foreign Keys, Check constraints, and maybe NULL /
NOT
> > NULL (specific type of check constraint) I intend to create (as
per
> > suggestion) pg_constraint.
>
> Hmmm...I don't see the need at all for NOT NULL constraint tracking.
The
> spec doesn't seem to require it and we do
On Fri, 2002-04-26 at 07:38, Curt Sampson wrote:
> On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> > WAL files are kept only until an fsync(), checkpoint, then reused.
>
> One could keep them longer though, if one really wanted to.
>
> > Also, the info is tied to direct locations in the file. Yo
Marc G. Fournier writes:
> Myself, I wonder why Oracle went the route they went ... does anyone have
> access to a Sybase / Informix system, to confirm how they do it? Is
> Oracle the 'odd man out', or are we going to be that? *Adding* something
> (ie. DROP TABLE rollbacks) that nobody appea
> For tracking of Foreign Keys, Check constraints, and maybe NULL / NOT
> NULL (specific type of check constraint) I intend to create (as per
> suggestion) pg_constraint.
Hmmm...I don't see the need at all for NOT NULL constraint tracking. The
spec doesn't seem to require it and we do not have n
36 matches
Mail list logo
