Ooer - it is a nasty bug. From pg_proc.h, the definition of
obj_description is:
select description from pg_description where objoid = $1 and classoid =
(select oid from pg_class where relname = $2 and relnamespace = PGNSP)
and objsubid = 0
And what's more, none of the SQL functions in pg_proc
How do I use a schema-qualified name in obj_description? Or is this a
nsty little bug?
Chris
test2=# create schema myschema;
CREATE SCHEMA
test2=# create table myschema.pg_class (a int4);
CREATE TABLE
test2=# select oid from pg_catalog.pg_class where
oid='myschema.pg_class'::regclass;
oid
-
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut - PostgreSQL wrote:
>> Cleanup on --help-config: Now called --describe-config, no further options,
>> machine readable, without headers, not sorted.
> Don't we need to document this? I don't see any SGML commits above.
It wasn't docume
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 20 Oct 2003, Bruce Momjian wrote:
>> I guess my question would be how many people are using information
>> schemas vs. have loaded databases they don't want to reload.
> We are still in beta, not RC ... why is this even an issue?
Given that
On Mon, 2003-10-20 at 23:15, Christopher Kings-Lynne wrote:
> > I suppose if all you want is backward compatibility which makes sense
> > for pg_dump, but surely psql should be forward thinking.
> >
> > Normally it's old clients with new server, not the other way around --
> > at least with big co
On Mon, 20 Oct 2003, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > I'm inclined to do it --- I don't get the sense that too many people
> > > have loaded large databases into 7.4 beta installations --- but if
> > > anyone wants to object now is the time.
> >
> > O
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> * Allow INET subnet tests using non-constants
>>> This should say "Allow ... to be indexed" as it's otherwise a nonissue.
> Uh, what should be in the TODO? I am confused.
"* Allow INET subnet tests using non-constants to be indexed"
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> It had occurred to me that we could move support for each version of the
> backend into a shared lib.
> eg. libpsql70.so, libpsql71.so, etc.
> Then all we do is load the appropriate lib and call functions in it. To
> support a newer version o
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> * Allow INET subnet tests using non-constants
> >> This should say "Allow ... to be indexed" as it's otherwise a nonissue.
>
> > New text is:
> > * Allow INET subnet tests to use indexes
> > Is that right?
>
I just ran into a new little anomaly in pg_autovacuum...
Note the interesting _negative_ numbers. Apparently something's
rolling over. I have no _grand_ problem with what happened, namely
"immediately checking again," as the system in question was doing
heavy offline updates. But this is likely
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Allow INET subnet tests using non-constants
>> This should say "Allow ... to be indexed" as it's otherwise a nonissue.
> New text is:
> * Allow INET subnet tests to use indexes
> Is that right?
No, because we already index sub
Peter Eisentraut - PostgreSQL wrote:
> CVSROOT: /cvsroot
> Module name: pgsql-server
> Changes by: [EMAIL PROTECTED] 03/10/18 19:59:09
>
> Modified files:
> src/backend/main: main.c
> src/backend/tcop: postgres.c
> src/backend/utils/misc: guc.c help_config.c
>
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > I'm inclined to do it --- I don't get the sense that too many people
> > have loaded large databases into 7.4 beta installations --- but if
> > anyone wants to object now is the time.
>
> Oops, I already did it. But if someone objects, it's an eas
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > What about bumping the libpq version?
>
> After thinking more, I realized we only need a minor version bump not
> major (AFAIR there were no backwards-incompatible API changes this time,
> only additions). That's already be
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > What about bumping the libpq version?
>
> After thinking more, I realized we only need a minor version bump not
> major (AFAIR there were no backwards-incompatible API changes this time,
> only additions). That's already be
I suppose if all you want is backward compatibility which makes sense
for pg_dump, but surely psql should be forward thinking.
>
Normally it's old clients with new server, not the other way around --
at least with big companies it seems easier to get a server upgraded
than everyones desktop.
Forwar
On Mon, 2003-10-20 at 22:39, Christopher Kings-Lynne wrote:
> > The tricky part seems to be dealing with i10n issues since the text to
> > translate would be release specific it needs to go into the backend --
> > but that isn't so nice.
>
> Why tricky? I'm just going to make the 7.5 psql utility
Tom Lane wrote:
> Some comments on random TODO entries:
>
> * Allow INET subnet tests using non-constants
>
> This should say "Allow ... to be indexed" as it's otherwise a nonissue.
New text is:
* Allow INET subnet tests to use indexes
Is that right?
> * ARRAYS
> o -Allow array
Tom Lane wrote:
> Not sure how this got missed, but we definitely need to increment the
> version number on libpq.so for 7.4.
I bump the minor when we start development. Was that skipped? Do we
need the major bumped?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL
The tricky part seems to be dealing with i10n issues since the text to
translate would be release specific it needs to go into the backend --
but that isn't so nice.
Why tricky? I'm just going to make the 7.5 psql utility work against
previous versions of postgresql. Any strings in that utility
> Going forward if we put the sql for all the psql commands into fuctions,
> then psql could be less tied to the backend version. I thought this was
> a TODO item already.
The tricky part seems to be dealing with i10n issues since the text to
translate would be release specific it needs to go int
On Mon, 2003-10-20 at 21:45, Christopher Kings-Lynne wrote:
> Looks fairly straightforward to me. Just need to get backend version
> out. Maybe handle v2 protocol again. Then just have different SQL for
> different backends.
Going forward if we put the sql for all the psql commands into fucti
I feel like looking into it, but tell me if I'm wasting my time...
Please do ...
I wonder what would it take. It only needs a different set of queries
to obtain info from the syscatalogs, or is it more involved?
Looks fairly straightforward to me. Just need to get backend version
out. Maybe
On Tue, Oct 21, 2003 at 09:26:12AM +0800, Christopher Kings-Lynne wrote:
> Is there demand for modifying psql to work against previous backends,
> pg_dump-style?
>
> I feel like looking into it, but tell me if I'm wasting my time...
Please do ...
I wonder what would it take. It only needs a d
Hi,
Is there demand for modifying psql to work against previous backends,
pg_dump-style?
I feel like looking into it, but tell me if I'm wasting my time...
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PR
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What about bumping the libpq version?
After thinking more, I realized we only need a minor version bump not
major (AFAIR there were no backwards-incompatible API changes this time,
only additions). That's already been done; so my gripe of yest
What about bumping the libpq version?
Chris
Marc G. Fournier wrote:
Just a quick note that we'd like to wrap up a Beta5 during the day
tomorrow, based on all the changes since Beta4 ... is anyone sitting on
any patches that postponing it "just one more day" would help ... ?
--
Tom Lane writes:
> I'm inclined to do it --- I don't get the sense that too many people
> have loaded large databases into 7.4 beta installations --- but if
> anyone wants to object now is the time.
Oops, I already did it. But if someone objects, it's an easy change back.
--
Peter Eisentraut
See subject. If we want to force an initdb to ensure the recent
information_schema updates take effect, we have to do it before beta5
release, I think.
I'm inclined to do it --- I don't get the sense that too many people
have loaded large databases into 7.4 beta installations --- but if
anyone wa
Christopher Browne <[EMAIL PROTECTED]> writes:
> How about a "flip side" for this...
> VACUUM CACHE;
> This new operation vacuums only those pages of relations that are in
> cache.
This might conceivably be a useful behavior (modulo the problem of
fixing index entries) ... but I think we'd not wa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I agree that depending on the system-provided locale behavior has its
>> downsides, but it has its upsides too;
> I like to think that in the end we can do much better than the POSIX
> framework can do.
Sure, we can make it work e
Tom Lane writes:
> I'm not sure that "supporting our own locale subsystem" really qualifies
> as "sustainable" ... can you give an estimate of how big the code +
> supporting data is likely to be?
It's not much worse than supporting our own character conversion subsystem
(which, btw., is somethin
The world rejoiced as [EMAIL PROTECTED] (Tom Lane) wrote:
> The latter point is really the crux of the problem. The point of having
> the VACUUM process is to keep maintenance work out of the critical path
> of foreground queries. Anything that moves even part of that
> maintenance work into the
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> On Mon, Oct 20, 2003 at 03:39:31PM -0400, Tom Lane wrote:
>> Whether the other approach would be any more future-proof is not clear
>> either.
> How standardized is row locking anyway?
Not at all, which is one reason I think that you might be fo
On Mon, Oct 20, 2003 at 03:39:31PM -0400, Tom Lane wrote:
>
> Impossible to say ... I wouldn't foresee any near-term changes, though.
> Whether the other approach would be any more future-proof is not clear
> either.
How standardized is row locking anyway? If I can just ensure that the
record st
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> One question though: how likely is the code to require changes for
> future postgres versions?
Impossible to say ... I wouldn't foresee any near-term changes, though.
Whether the other approach would be any more future-proof is not clear
either.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> If we have to write our own locale
>> support it's likely to be a long time coming :-(
> Naturally, I cannot promise anything, but this is at the top of my list
> for the next release. I already have sorted out the specifications
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Mon, 20 Oct 2003, Tom Lane wrote:
>> I noticed by chance that glibc has a "reentrant locale" API that seems
>> to allow for efficient access to multiple locales concurrently.
> Where have you found this?
It's present in RH8 --- there is plus vari
On Mon, Oct 20, 2003 at 08:56:05PM +0200, ivan wrote:
> how put password to psql, pg_dump etc by same shell script (for ie by
> crontab) , because there are option -W but passwd is reading from /dev/tty
> not from stdin , so i can not use | :(
Have you tried the ~/.pgpass file or the PGPASSWORD e
On Mon, Oct 20, 2003 at 01:35:13PM -0400, Tom Lane wrote:
>
> It's not actually a record in the database ... pg_locks is a view of
> internal lock-manager state. (It's new as of 7.3, BTW; dunno how far
> back you want your stuff to work.) But it will get the job done for
> you.
Sure beats what
hi,
how put password to psql, pg_dump etc by same shell script (for ie by
crontab) , because there are option -W but passwd is reading from /dev/tty
not from stdin , so i can not use | :(
---(end of broadcast)---
TIP 6: Have you searched our list
Peter Eisentraut kirjutas E, 20.10.2003 kell 21:02:
> Tom Lane writes:
>
> > I noticed by chance that glibc has a "reentrant locale" API that seems
> > to allow for efficient access to multiple locales concurrently. Perhaps
> > it would be a reasonable solution to support multiple locales only on
Tom Lane writes:
> I noticed by chance that glibc has a "reentrant locale" API that seems
> to allow for efficient access to multiple locales concurrently. Perhaps
> it would be a reasonable solution to support multiple locales only on
> machines that have this library. If we have to write our o
On Mon, 20 Oct 2003, Tom Lane wrote:
> I noticed by chance that glibc has a "reentrant locale" API that seems
> to allow for efficient access to multiple locales concurrently.
Where have you found this?
I've been looking for that but have not found it. I run a rh9 system, do
you have something n
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> On Mon, Oct 20, 2003 at 12:18:44PM -0400, Tom Lane wrote:
>> Another way you can look to see if a transaction has completed is to see
>> if there is still an ExclusiveLock record for it in pg_locks. For this
>> you need to know the transaction's
On Mon, Oct 20, 2003 at 12:18:44PM -0400, Tom Lane wrote:
> Another way you can look to see if a transaction has completed is to see
> if there is still an ExclusiveLock record for it in pg_locks. For this
> you need to know the transaction's internal XID, but you can get that
> from the XMAX of
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > You keep ignoring the problem of removing index entries. To vacuum an
> > individual page, you need to be willing to read in (and update) all
> > index pages that reference the tuples-to-be-deleted.
>
> Hm. I
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Some of you may remember that we discussed libpqxx's higher-level
> support for transactionality.
> [complicated scheme]
Another way you can look to see if a transaction has completed is to see
if there is still an ExclusiveLock record for it
Just a quick note that we'd like to wrap up a Beta5 during the day
tomorrow, based on all the changes since Beta4 ... is anyone sitting on
any patches that postponing it "just one more day" would help ... ?
---(end of broadcast)---
TIP 8: explain an
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> If an index tuple had transaction information duplicated along with
> heap tuple, two types of tuples can be removed, independent of each
> other?
Possibly ... but I think we have already considered and rejected that
proposal, more than once.
Tom Lane <[EMAIL PROTECTED]> writes:
> You keep ignoring the problem of removing index entries. To vacuum an
> individual page, you need to be willing to read in (and update) all
> index pages that reference the tuples-to-be-deleted.
Hm. If the visibility information were stored in the index
Tom Lane wrote:
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
I was thinking about it. How about vacuuming a page when it is been
pushed out of postgresql buffer cache? It is is memory so not much IO
is involved.
You keep ignoring the problem of removing index entries. To vacuum an
individua
[EMAIL PROTECTED] (Sailesh Krishnamurthy) writes:
>> "Christopher" == Christopher Browne <[EMAIL PROTECTED]> writes:
> Christopher> Ah, but do "papers" honestly indicate the emergence
> Christopher> of some underlying theoretical model for which
> Christopher> fidelity could be eval
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> I was thinking about it. How about vacuuming a page when it is been
> pushed out of postgresql buffer cache? It is is memory so not much IO
> is involved.
You keep ignoring the problem of removing index entries. To vacuum an
individual page, you n
Some of you may remember that we discussed libpqxx's higher-level
support for transactionality.
It was pointed out (by Tom, IIRC) that the connection to the backend
may be lost just after you've sent out the commit, while you're still
waiting for a confirmation. So I built a class that expends
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tatsuo Ishii kirjutas E, 20.10.2003 kell 15:37:
>> There's absolutely no relationship between database encoding and
>> locale.
> How does the system then use locale for sorting and not for upper/lower
> ?
LC_COLLATE and LC_CTYPE are independent setting
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> It's been suggested that we could use where available.
>> However there are a bunch of issues that would have to be solved to make
>> that happen. (How do we convert between the database character encoding
>> and the wctype representation?
> How do
Tatsuo Ishii kirjutas E, 20.10.2003 kell 15:37:
> > Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> > > Oliver Elphick <[EMAIL PROTECTED]> writes:
> > > > There is a bug in Unicode upper() which has been present since 7.2:
> > >
> > > We don't support upper/lower in multibyte character sets, and can
> Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> > Oliver Elphick <[EMAIL PROTECTED]> writes:
> > > There is a bug in Unicode upper() which has been present since 7.2:
> >
> > We don't support upper/lower in multibyte character sets, and can't as
> > long as the functionality is dependent on 's tou
On Sun, Oct 19, 2003 at 12:09:35PM -0400, Tom Lane wrote:
> The bug reporter is in error to be claiming he is running 7.3.3, because
> the assert() in question is at line 334 not 331 in 7.3.3. He may have
> 7.3.3 client libraries, but he must be talking to a server version
> between 7.3 and 7.3.2.
I noticed that the function to get max builtin OID for 7.0 does this:
template1=> SELECT oid from pg_database where datname = 'template1';
oid
---
17216
(1 row)
However, that is incorrect:
template1=> select oid,relname from pg_class where oid > 17216;
oid | relname
---+---
Tom Lane writes:
> >> o Add SET SCHEMA
> >>
> >> What is this supposed to do (and how's it different from SET SEARCH_PATH)?
>
> > I believe someone thought it was the SQL standard way of doing it.
> > Probably needs to be checked though.
>
> I can find no mention of it in SQL99. Given that the sp
Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > There is a bug in Unicode upper() which has been present since 7.2:
>
> We don't support upper/lower in multibyte character sets, and can't as
> long as the functionality is dependent on 's toupper()/tolow
63 matches
Mail list logo
