> CREATE RULE PasTouche AS ON UPDATE TO foo
> WHERE old.locked=TRUE
> DO INSTEAD ERROR;
>
> I think this simple new rule action could be added to pg.
> I'm planning to do it, if there is no opposition.
> Any comments on this proposed new rule action?
> Or did I missed something obvi
> I think most of the current contrib projects are more missing the
> advantage version independence would have for the ease of "sitting" in
> contrib and having the whole project management around them just done.
> Yes, doing your own gborg project costs time. You have to maintain
> pages, do
On Wed, 2004-04-21 at 21:29, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
>
> > > I think most of the current contrib projects are more missing the
> > > advantage version independence would have for the ease of "sitting" in
> >
> The point of projects.postgresql.org is that if someone *is* looking for
> an addon, they should be pointed to projects.postgresql.org ... if you try
> and merge everything into the -core distribution, you are either going to
> miss something that *someone* wants to use at some point, *or* one he
On Wed, 2004-04-21 at 22:43, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
>
> > We have the current issue of people not knowing that projects like
> > pgadmin exist or where to find the jdbc drivers.
>
> Agreed ... but makign one big META package
On Thu, 2004-04-22 at 20:09, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
>
> > I guess that is where we differ in opinion. pgadmin is not addon or an
> > enhancement, it is a part of the core project every bit as much as the
> > gnome-panel is a pa
On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> On Thursday 22 April 2004 13:55, Barry Lind wrote:
> > I think the solution lies in improving www.postgresql.org. At the end
> > of the day it doesn't matter where source code lives, what matters is
> > can people find what they are expecting. Gi
> The difference is that a "better" admin tool is very subjective where as
> a buffer strategy is not... or maybe the difference is really that
> everyone thinks they are qualified to pick a "better" admin tool, but
> very few can really argue as to a better buffer strategy. While I think
> your cr
> 5. If the identifier is lowercase only, convert it to uppercase only. I
> am assuming here that the authors of the client code chose an
> uppercase-folding database, so they should know what they are doing when
> accessing stuff from the standard offering.
You've just broken one of my databas
> I'm not sure you understood me.
Perhaps not, here is what we have:
\c template_db
CREATE TABLE "example" ( "col" integer);
CREATE DATABASE newdb WITH TEMPLATE template_db UPPERCASE IDENTIFIERS;
\c newdb
SELECT "col" FROM "example";
> In short, I don't think this suggestion broke your databa
> > Also, should the syntax be SET TYPE, not just TYPE?
>
> Shrug ... I dunno whether Rod had a precedent for that choice or not.
FireBird: ALTER COLUMN TYPE
DB2:ALTER COLUMN SET DATA TYPE .
Oracle: MODIFY
MSSQL: ALTER COLUMN
MySQL: Both Oracle and MSSQL
Sap:MODIFY
Spec: No
> I did say we needed more docs effort
Yes, where should the docs for this go? The Alter table reference page,
or Chapter 5.5 titled "Modifying Tables"?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
> CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT
> nextval('doc.seq_doc_id'::text)
> CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ;
>
> I did not notice any similar error report on the list, so I believe that this
> is not fixed yet ?
It comes out right for me in 7.4.2.
> However, when I tried TCP socket, Pgpool was actually
> slower by 15x !! Perhaps you can clarify why the TCP
> socket is so much slower?
How did you have pgpool configured to connect to the database? Domain
socket or tcpip?
---(end of broadcast)-
> > Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
> > (basically following the same rules as ALTER TABLE).
>
> Interesting --- you would have to rebuild every table that uses the
> domain, and map from-to for all stored values of the domain.
>
> TODO item?
Yes. This i
On Thu, 2004-05-06 at 13:23, Merlin Moncure wrote:
> > Yes. This is something I was going to look at doing in the next
> release.
>
> Quick question:
> With your potential changes, you would then be able to alter a domain
> that is involved in RI constraints between 2 or more tables without
> bri
> If we were willing to abuse the ALTER TABLE syntax some more, it would
> be possible to support changing the datatypes of f1 and f2
> simultaneously, thereby allowing the above to work. The infrastructure
> for hacking multiple tables in parallel is already there in CVS tip,
> but it only gets e
On Wed, 2004-05-05 at 00:45, Christopher Kings-Lynne wrote:
> > Yup.. And some of us intend on wrapping every single statement in a
> > subtransaction so we can rollback on an error without aborting the main
> > transaction.
>
> Point there being "main transaction". What i'm saying is that the va
On Wed, 2004-05-05 at 00:22, Christopher Kings-Lynne wrote:
> > I hope not, because for many of us there will be as many (if not more)
> > subtransactions than standard transactions.
>
> How can that possibly be true? Every statement executed in postgres is
> a "transaction" how many subtransac
> And "preforking" makes this different, how ? Perhaps having a pool of
> processes ready to be handed a query to a specific database, where you
> configure N connections to db1, M to db2 etc. still means lots of resource
> usage. In effect a preforked database server *is* an idle connection, just
d transactions.
--
Rod Taylor
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/signature.asc
signature.asc
Description: This is a digitally signed message part
The function format_type() fails only for interval when used on the
interval type
template1=# select format_type(oid, typlen) from pg_type;
ERROR: invalid INTERVAL typmod: 0xc
template1=# select format_type(oid, typlen) from pg_type where typname
!= 'interval';
-- Many results
On Mon, 2004-04-26 at 22:04, Alvaro Herrera wrote:
> On Mon, Apr 26, 2004 at 09:36:26PM -0400, Rod Taylor wrote:
> > The function format_type() fails only for interval when used on the
> > interval type
> >
> > template1=# select format_type(oid, typlen) from pg_type;
> > How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs
> > (depending on how stable it gets)?
>
> Zero chance ... Slony-I is *a* replication solution, not *the*
> replication solution ... unless someone ever comes up with an 'end all and
Not to mention Jan doesn't want
> Overall, I'd refer back to the points Bruce raised - you certainly do
> need a way of finding out the time to recover to, and as others have
> said also, time isn't the only desirable "recovery point".
Wouldn't it be sufficient to simply use the transaction ID and ensure
that all the parameters
On Tue, 2004-04-27 at 17:36, Simon Riggs wrote:
> On Tue, 2004-04-27 at 21:56, Rod Taylor wrote:
> > > Overall, I'd refer back to the points Bruce raised - you certainly do
> > > need a way of finding out the time to recover to, and as others have
> > > said
> I know the issue of pre-fork PostgreSQL has been discussed previously.
> Someone mentionned pre-fork can be implemented when schemas become available
> Any chance of that happening for 7.5?
0 chance unless you have a patch ready now.
---(end of broadcast)--
> Or, you run several seperate Apache webservers. The ones that serve static
> content or don't need database connections don't run with the ones that do.
> And just like each idle Apache process uses memory and other resources,
> each idle PostgreSQL connection does to. So managing the number o
On Wed, 2004-05-05 at 11:57, Greg Stark wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
>
> > Cutting that count down to 10 idlers in total by having PostgreSQL
> > prefork a specific database would make a significant difference.
>
> Well it would be 10 for ea
On Wed, 2004-05-05 at 13:48, Bruce Momjian wrote:
> I am seeing the following failure of initdb in CVS:
>
> FATAL: invalid value for parameter "client_encoding": ""
I get the same thing.
---(end of broadcast)---
TIP 5: Have you checked o
> And, of course, most development environments (perl, php, java etc)
> have their own language specific connection pooling solutions.
Yes, the one for php is what I was thinking of when I made my statement.
They work on a per backend basis as Apache does not allow for the type
of communication be
> > I cannot tell if mod_pg_pool works across Apache forked backends or is
> > still bound to a single process. They state it is intended for sharing
> > connections across modules, so it is probably still backend specific.
>
> Have you looked at sqlrealy.sourceforge.net? IT looks like it might d
On Sun, 2004-05-16 at 23:02, Marc G. Fournier wrote:
> On Sun, 16 May 2004, Bruce Momjian wrote:
>
> > I personally don't think Win32 is enough of a new feature either, but
> > others disagree.
>
> Jan, correct me if I'm wrong ... Jan's point is that we have enough
> already to warrant a beta on
On Wed, 2004-02-11 at 16:36, [EMAIL PROTECTED] wrote:
> Hi, all
>
> What should I do if I want to have 2 completely seperated databases in
> PostgreSQL? I want each database to have its own data, log and
> everything needed to access that database. I don't want them to share
> anything. Has anyone
As a result of the constraint output functions being shared between
pg_dump and psql, some of the output is mis-quoted in the display area
for columns including quotes. Notice it's correct in the table Column
list, but the constraint has the escaped versions.
Thoughts?
rt=# create table c ("""ver
> create function crashme2() returns int strict language plpgsql as '
> begin
>subbegin;
> select foo; -- aborts the transaction
> -- did not close the subxact
> end;';
I'm not sure I follow. Are you saying that the following code or
something similar wi
> Some sort of modification will be needed to the error processing
> mechanism, but this is beyond me at this point ... I don't have any
> idea how could this be.
So.. If you cannot rollback a subtransaction within a plpgsql function
(all function types or just that one?) then there is no point i
On Fri, 2004-07-09 at 09:29, Stephen Frost wrote:
> * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > >Personally, I would love to see this in PostgreSQL. It'd be great if it
> > >could get into 7.5. An issue I see with that is that (similar to
> > >Oracle...) I think people would want to
On Fri, 2004-07-09 at 10:14, Rod Taylor wrote:
> On Fri, 2004-07-09 at 09:29, Stephen Frost wrote:
> > * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > > >Personally, I would love to see this in PostgreSQL. It'd be great if it
> > > >could get into
> > Simply setup a tablespace for a given user with permissions to allow
> > only that user to create new objects within it and make it the default
> > location) -- tie their schema to their tablespace? -- then set a kernel
> > level quota on their tablespace.
>
> Since the user accessing/writing
> > > Since the user accessing/writing to the tablespaces would be the
> > > postgres user I don't really think this 'solution' works in reality.
> >
> > I had assumed it would be a directory based quota rather than a user
> > based one.
>
> It's been a while since I played with quotas but I don'
> > Group quotas should be sufficient. Create directory readable/writable to
> > only the pgsql user, but have the group ownership be representative of
> > the user in question.
>
> Rather ugly, and you'll run out of groups if you have alot of users (the
> postgres user can only be in so many grou
On Fri, 2004-07-09 at 11:47, Stephen Frost wrote:
> * Klaus Naumann ([EMAIL PROTECTED]) wrote:
> > On Thu, 8 Jul 2004, Jonah H. Harris wrote:
> > > 3. The maximum quota size is (currently) the maximum of int4*1024 bytes.
> >
> > why is this? This is very limiting ...
>
> It's 2TB...
Okay.. that
On Sun, 2004-07-11 at 20:57, Bruce Momjian wrote:
> I can do that for 7.6. Is it worth it? Is it a TODO?
I'm not sure what Christopher mentioned is the correct fix. The
information is displayed correctly in all places except where a
pg_get_.* function is used (indexes, constraints, etc.).
Those
I remember a thread about pretty-print functions. Are those used? This
is probably the best place to put the fix, since they already munge
things for display purposes.
On Sun, 2004-07-11 at 21:33, Christopher Kings-Lynne wrote:
> It should be done, otherwise you cannot copy and paste foreign key
On Sun, 2004-07-11 at 21:34, Christopher Kings-Lynne wrote:
> > I'm not sure what Christopher mentioned is the correct fix. The
> > information is displayed correctly in all places except where a
> > pg_get_.* function is used (indexes, constraints, etc.).
>
> The name of the constraint (ie. the "
> However, looking at how the Linux community handles it, I think we can
> borrow a lot of concepts from them.
I was thinking quite the opposite. The Linux community doesn't exactly
have a great track-record for their stable releases.
The thoughts behind the process might be good, but do we have
On Tue, 2004-07-13 at 20:49, Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Tom Lane wrote:
>
> > We could certainly do something along that line if we had a few people
> > willing to be "gatekeepers". We'd have to work harder at making the
> > release generation process open and documented tho
On Sun, 2004-07-18 at 07:42, Christopher Kings-Lynne wrote:
> > I am not sure that is really a bug. If someone really wants less than
> > what is in template1, they should be dropping stuff from template1
> > before recreating the database.
>
> No, because pg_dump itself dumps template1's contents
On Sun, 2004-07-18 at 23:55, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I think what we want is a clean template without all of the extras that
> > template1 has.
>
> Sounds like a job for ... template0 !
It doesn't quite work in my case a
On Mon, 2004-07-19 at 12:36, Josh Berkus wrote:
> Rod,
>
> > I think what we want is a clean template without all of the extras that
> > template1 has.
>
> We have this, it's called Template0.
Doesn't work for me. I remove a number of things that are included by
default in template0, but yes, it
On Mon, 2004-07-19 at 13:30, Josh Berkus wrote:
> Rod,
>
> > Remove the public schema from template0, but leave it in template1. Have
> > pg_dump treat the public schema the same as all of the other ones.
>
> Hmmm. No good; it wipes out the primary purpose of Template0, which is to
> restore a
On Mon, 2004-07-19 at 21:20, Christopher Kings-Lynne wrote:
> > We already are to some extent, since pg_dump will dump its comment and
> > privileges, which it would not do for any other predefined object.
> > I think this is actually an implementation artifact rather than
> > something that was ex
> I don't know why the 1st VACUUM FULL wasn't able to reclaim the same
> amount of space as the 2nd one, but I would guess that it wasn't able to
> get a lock on some table. It could have been autovac if it was doing a
> vacuum at that moment, but it could have been something else too.
Or ther
> What happens when a transaction fails to either commit or abort as a
> result of a serious error?
>
> That looks like a transaction-in-progress doesn't it?
>
> Would that prevent VACUUM from doing its work? It should be able to
> check the last startup xid to check that isn't the case, but sup
> Looks good ... I wonder if it can be configured to show tabs as 4
> spaces, to match Postgres current practice? Also, as Tom already
> pointed out, the $PostgreSQL$ header is not honored.
I bet you the $PostgreSQL$ header can be configured into it -- it seems
to accommodate $FreeBSD$ and other
> How do you then audit a TRUNCATE performed by somebody else (who, for
> "political" reasons, has superuser access)? Such actions aren't limited to
> attacks - but may simply be the result of "I thought it was a good idea at
> the time". :-(
Easily enough, have the logs record the pid, connecti
> You seem to be suggesting that using the id is less useful than the
> time, but surely it's going to be easier to say "this disaster happened
> in transaction 123 so lets do a PITR up to 122" than to say "this
Transaction IDs are assigned at transaction start but what you really
want is some ind
On Tue, 2004-08-03 at 23:36, Christopher Kings-Lynne wrote:
> I think we need to deny changing column types if a function is using the
> table type as a return set.
>
> test=# create table test (a int4);
> CREATE TABLE
> test=# create function test () returns setof test as 'select 1' language
>
On Fri, 2003-09-26 at 13:58, Bruce Momjian wrote:
> Patrick Welche wrote:
> > On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
> > ...
> > > if we are talking two computers sitting next to each other on a switch,
> > > you'd expect those to be low ... but if you were talking about
> The first problem is the restart/rejoin problem. When a 2PC member
> goes away, it is supposed to come back with all its former locks and
> everything in place, so that it can know what to do. This is also
> extremely tricky, but I think the answer is sort of easy. A member
> which re-joins wi
> > Actually, all that's really necessary is the ability to call a stored
> > procedure when some event occurs. The stored procedure can take it from
> > there, and since it can be written in C it can do anything the postgres
> > user can do (for good or for ill, of course).
>
> But the postmaste
I have a few questions (below).
Mechanism:
1) Rename the old column to ...pg.dropped... to get it out of
the way of step 2.
2) Create a new column with the wanted type and appropriate
constraints. Only not null is supported at the moment.
3
A. On Mon, 2003-09-29 at 10:28, Christof Petig wrote:
> Rod Taylor schrieb:
> > Is this syntax ok?
> > ALTER TABLE ALTER COLUMN TYPE > type>
>
> shouldn't that be
>ALTER TABLE ALTER [COLUMN] [TYPE]
> w
> Perhaps the ALTER command could include an optional clause "TRANSFORM
> expr-on-oldcol" to do this. In that case, defaulting to assignment
> coercion would be fine with me.
This would certainly be interesting and shouldn't take too much to
accomplish for simple expressions. If we allow the full
> > It seems that one way out is just to fall back to "read only" as soon
> > as a single failure happens. That's the least graceful but maybe
> > safest approach to failure, analogous to what fsck does to your root
> > filesystem at boot time. Of course, since there's no "read only"
> > mode at
> No, I'm not. One needs to decide how to handle the situation where a
> slave database in a 2PC transaction goes away and comes back, for
> whatever reasons that may happen. Since the idea here is to come up
> with ways of handling the failure of 2PC in some cases, we need
> something which noti
On Mon, 2003-09-29 at 15:55, Peter Eisentraut wrote:
> Manfred Spraul writes:
>
> > Ok. Lets assume one coordinator, two partitipants.
> > Global commit send to both by coordinator. One replies with ok, the
> > other one remains silent.
> > What should the coordinator do? It can't fail the transac
> It doesn't seem to me that this really buys much. What we really want
> is a way for a dump/reload to remove OIDs from tables that formerly had
> them; otherwise people will not easily be able to migrate their existing
> tables away from having OIDs.
Doesn't ALTER TABLE ... SET WITHOUT OIDS all
> For example, if you have a timestamp index and you routinely clean out
> all entries older than N-days-ago, you won't have a problem in 7.4.
> If your pattern is to delete nine out of every ten entries (maybe you
> drop minute-by-minute entries and keep only hourly entries after awhile)
> then y
>+ CREATE SCHEMA: Sometimes a schema created in PostgreSQL
> disappears if there is nothing in it.
If true, this would be a bug. Do you have a reproducible test case?
>+ CREATE INDEX: PostgreSQL should allow specifying a namespace
> for the index, even if the namespace is requi
On Tue, 2003-09-30 at 00:10, Steve Yalovitser wrote:
> Hello,
>
> I'd like to know if its possible to coopt the postgres storage subsystem to
> rely entirely on ram based structures, rather than disk. Any documentation
> or ideas would be appreciated.
Just so you know, this isn't going to make th
> Hm. The parallel regression tests require at least 20. I deliberately
> allowed initdb to select values as small as 10 on the theory that
> installing and not being able to run the parallel regression tests is
> better than not installing at all. Does anyone want to argue the
> opposite? Perh
> It almost certainly would, but I was assuming we had to consider this in
> the context of loading existing dump files. We could think about having
> pg_dump emit an automatic ANALYZE after the data loading step in the
> future though.
Rather than running ANALYZE, how about simply dumping out an
Below is a 7.2.4 example of the rserv log with inet data type. You will
notice that inet cast to text, and the log entry are differently (one
from unknown directly to text via a trigger, the other from inet cast to
text).
I see this hasn't been changed in the 7.4 version. Is there intent on
removi
On Tue, 2003-10-07 at 21:31, Christopher Kings-Lynne wrote:
> > Should we add a variable that is set from the dump filew that identifies
> > the version of PostgreSQL that generated the dump?
> >
> > SET dumped_version = 7.3
>
> With something like that, does it have to be reissued after ever
On Thu, 2003-10-09 at 11:14, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > If you want cross-server transactions, what other methods are there that
> > are more reliable?
>
> 3-phase commit
How about a real world example of a transaction manager that has
actually implemented 3PC?
But ye
Below is a short script which causes an error in the foreign key plan
caching. It appears to cause the error with or without the transaction,
but closing the connection between steps causes it to go away.
Can the cache be cleared after each statement?
Error reported:
psql:/home/rbt/bugte
May have posted this earlier...
It would seem that caching the plans for foreign keys has some unwanted
side effects.
test=# select version();
version
PostgreSQL 7.4beta4 on i386-portbld-fr
> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> >> > constraints/triggers, not settable from postgresql.conf?
> >>
> >> Is that one really necessary for 7.4 now that adding foreign keys is
> >> apparently much faster?
> If you reconfigure your systems to force fs
> I think another way it could be handled is with nested transactions.
> Just have the promise phase be an inner transaction commit but have an
> outer transaction bracket that one for the actual commit.
Not really. In the event of a crash, most 2PC systems will expect the
participant to come back
On Mon, 2003-10-13 at 21:26, Jan Wieck wrote:
> Rod Taylor wrote:
> >> >> > Allow superuser (dba?) the ability to turn off foreign key checks/all
> >> >> > constraints/triggers, not settable from postgresql.conf?
> >> >>
> >> >&
> >> Some dumb-user/fat-finger/ooops protection is surely welcome, but there
> >> is a limit. A system console has to be behind a locked door instead of
> >> the single-user boot being root-password protected. As soon as people
> >
> > Unfortunately, as more and more companies start to outsourc
> > I wouldn't want the whole diff on the mail, but a link to the relevant
> > diffs in cvsweb would be most useful (one for each changed file -- not ideal,
> > but much better than nothing). You're not the first one to suggest it ...
>
> I agree, it would be very useful. Marc, would it be possib
> The vacuum man page says, "FREEZE is not recommnded for routine use".
> That was enough to keep me away. However if vacuum freeze was
> considerably lighter than normal database wide vacuums then there might
> be an advantage to using it. Especially since when pg_autovaccum
> decides it's tim
> So, pg_autovacuum does deal with them separately, but doesn't make an
> effort to spread out the vacuums if all / multiple databases happen to
> need it at the same time.
>
> In practice, I don't see this as a big problem right now, but it should
> still be handled better by pg_autovacuum.
I un
On Fri, 2003-10-17 at 10:22, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > What part of plain vacuum takes disk bandwidth?
>
> Reading (and possibly rewriting) all the pages.
Would it be possible for the backend to keep a list of the first N (N
being a large number but not
> 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 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
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 Tue, 2003-10-21 at 00:08, Tom Lane wrote:
> 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
On Tue, 2003-10-21 at 09:03, Andreas Pflug wrote:
> Rod Taylor wrote:
>
> > I'm sure the pgAdmin group likes that idea (they're probably tired of maintaining
> > 4 different versions of
> >queries for getting a list of tables). Any solution to make psql backwar
On Tue, 2003-10-21 at 09:33, Andreas Pflug wrote:
> Rod Taylor wrote:
>
> >
> >Of course, psql has the same issue in hiding functionality that doesn't
> >exist. My biggest beef is the psql help is often misleading if you're
> >connected to a different back
On Tue, 2003-10-21 at 21:24, Christopher Kings-Lynne wrote:
> > There is always the biggest evil of all... Putting SHOW / DESCRIBE /
> > HELP commands into the backend itself. I'm sure the pgAdmin group likes
> > that idea (they're probably tired of maintaining 4 different versions of
> > queries f
On Wed, 2003-10-22 at 04:01, Christopher Kings-Lynne wrote:
> Hi guys,
>
> What is the limit on the number of rows in a PostgreSQL table? If it's
> more than MAXINT, we have a problem:
>
> phppgadmin# select * from test limit 2147483648;
> ERROR: integer out of range
>
> Same problem with OFF
On Wed, 2003-10-22 at 10:22, Christopher Kings-Lynne wrote:
> > I see you're point, but nobody is going to be interested in the first 2
> > billion rows of a table without using a cursor and having some other
> > process do the math in the background.
>
> You have the same problem:
> test=# move
On Wed, 2003-10-22 at 12:08, scott.marlowe wrote:
> On Wed, 22 Oct 2003, Tom Lane wrote:
>
> > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > That said, perhaps the TODO for changing LIMIT / OFFSET to be expression
> > > based should also mention bumping them
> >Nay... I would expect a PostgreSQL specific information_schema to get
> >just as much mucking around as the system tables, which means you are
> >still maintaining a set of queries per release.
> >
> >
> The problem about information_schema is that it's restricted to show
> objects of the own
Linux ns2 2.4.20-xfs #2 Tue Apr 15 10:04:43 EDT 2003 i686 unknown
<-- SNIP -->
stats... FAILED
== shutting down postmaster ==
===
1 of 93 tests failed.
===
*** ./expected/stats.outSat Se
> Anyway, it seems like we need a vote to see how many people prefer
> each choice.
I say leave it the way it is. If you want system table tab completion,
simply:
ALTER USER ... SET search_path = pg_catalog,...;
I would like to see the information_schema be a part of the default
search_p
701 - 800 of 994 matches
Mail list logo
