Tom Lane writes:
> Right. "Portably" was the key word in my comment (sorry for not
> emphasizing this more clearly). The real problem here is how to know
> what is the actual behavior of each platform? I'm certainly not
> prepared to trust reading-between-the-lines-of-some-man-pages. And I
>
>>>Neil Conway said:
> 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
If ever this happens, same should be considered for tables created via the
SELECT INTO statement. These are in many cases 'temporary' in nature and do
not need OIDs (while making much use of the OIDs counter).
Daniel
---(end of broadcast)---
TIP
Ok guys, I propose that the new libpq diff and 2 source files which
i'll soon send to pgsql-patches is applied to the source. This diff is
a cleaned up version of the previous version with the wrapper
functions moved out into their own file and more comments added. Also
the use of crypt_r() has bee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
> I have no problem with ads being put there, but they should load at
> least as fast as the rest of the site. They do so currently, but not
> always, it seems...
The ads are coming from another
On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote:
> > FTP is just over 800MB, plan for growth.
> > WEB is just over 90MB, can't tell you what to plan for there.
>
> Sorry to be dense, but what time period is this for?
Any given day. It's disk space, not traffic.
> > On www/ftp.us I don't even notice
On 13 Jan 2003 at 9:45, Vince Vielhaber wrote:
> On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > > FTP is just over 800MB, plan for growth.
> > > WEB is just over 90MB, can't tell you what to plan for there.
> >
> > Sorry to be dense, but what time period is this for?
>
> Any given day. It's
On Mon, Jan 13, 2003 at 11:59:33AM +0800, Christopher Kings-Lynne wrote:
>Tom Lane writes:
> >
> > Feel free to contribute some code.
>
> I will, but unfortunately the damage has already been done...since I have to
> support 7.3 anyway, fixing the above problem will actually make my life
> harder,
On Mon, 13 Jan 2003, Dan Langille wrote:
> On 13 Jan 2003 at 9:45, Vince Vielhaber wrote:
>
> > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote:
> >
> > > > FTP is just over 800MB, plan for growth.
> > > > WEB is just over 90MB, can't tell you what to plan for there.
> > >
> > > Sorry to be dense, but
On Mon, Jan 13, 2003 at 10:01:38AM -0500, Vince Vielhaber wrote:
> On Mon, 13 Jan 2003, Dan Langille wrote:
>
> > On 13 Jan 2003 at 9:45, Vince Vielhaber wrote:
> >
> > > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote:
> > >
> > > > > FTP is just over 800MB, plan for growth.
> > > > > WEB is just ove
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> If ever this happens, same should be considered for tables created via the
> SELECT INTO statement. These are in many cases 'temporary' in nature and do
> not need OIDs (while making much use of the OIDs counter).
SELECT INTO does create tables withou
On Mon, 13 Jan 2003, Ross J. Reedstrom wrote:
> On Mon, Jan 13, 2003 at 10:01:38AM -0500, Vince Vielhaber wrote:
> > On Mon, 13 Jan 2003, Dan Langille wrote:
> >
> > > On 13 Jan 2003 at 9:45, Vince Vielhaber wrote:
> > >
> > > > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote:
> > > >
> > > > > > FTP
Hi!
I just came across a posting in this list, and a question arose from that
which I'm carrying for some time. PG has *some* views in the system catalog,
which make life easier, but some essential(?) things like 'list all tables in
DB' has to be done in a multi-table join with special attribut
Joerg Hessdoerfer <[EMAIL PROTECTED]> writes:
> PG has *some* views in the system catalog, which make life easier, but
> some essential(?) things like 'list all tables in DB' has to be done
> in a multi-table join with special attributes. What is the rationale
> of that? Wouldn't it be easier (and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
> Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs.
> psql) to have views for that? Do I miss a point here?
Putting the \d commands into views has been on the TODO list f
> -Original Message-
> From: Ross J. Reedstrom [mailto:[EMAIL PROTECTED]]
> Sent: 13 January 2003 15:16
> To: Vince Vielhaber
> Cc: Dan Langille; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] PostgreSQL site, put up or shut up?
>
>
> And there was a statement upthread from someone (Marc?)
On Mon, 2003-01-13 at 11:28, [EMAIL PROTECTED] wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
>
>
> > Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs.
> > psql) to have views for that? Do I miss a point he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
> Go back and reread the end of it. The first part was about the ads,
> the second was about mirrors.
Sorry for the confusion: Dave is right, I just asked the question wrong.
I am not really co
> On Mon, Jan 13, 2003 at 11:59:33AM +0800, Christopher Kings-Lynne wrote:
> >
> > I will, but unfortunately the damage has already been done...since I
have to
> > support 7.3 anyway, fixing the above problem will actually make my life
> > harder, not easier...
Another issue to consider is that
On Mon, 13 Jan 2003, Dave Page wrote:
>
>
> > -Original Message-
> > From: Ross J. Reedstrom [mailto:[EMAIL PROTECTED]]
> > Sent: 13 January 2003 15:16
> > To: Vince Vielhaber
> > Cc: Dan Langille; [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] PostgreSQL site, put up or shut up?
> >
> >
> >
> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> Sent: 13 January 2003 15:42
> To: Dave Page
> Cc: Ross J. Reedstrom; Dan Langille; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] PostgreSQL site, put up or shut up?
>
>
> On Mon, 13 Jan 2003, Dave Page wrote:
> >
>
On Mon, 2003-01-13 at 11:28, [EMAIL PROTECTED] wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
>
>
> > Wouldn't it be easier (and more portable, see 7.3/7.2 system catalogs vs.
> > psql) to have views for that? Do I miss a point
Oh!
That's an excellent idea. Seemingly addresses the issue and has
value-add. I'm not aware of any gotchas here. Is there something that
is being overlooked?
Greg
On Mon, 2003-01-13 at 14:50, Robert Treat wrote:
> On Mon, 2003-01-13 at 11:28, [EMAIL PROTECTED] wrote:
> >
> > -BEGIN PG
On Mon, 2003-01-13 at 10:47, Dave Page wrote:
>
>
> > -Original Message-
> > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> > Sent: 13 January 2003 15:42
> > To: Dave Page
> > Cc: Ross J. Reedstrom; Dan Langille; [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] PostgreSQL site, put up or
On Mon, 13 Jan 2003, Dave Page wrote:
> > On Mon, 13 Jan 2003, Dave Page wrote:
> > >
> > > Total Hits 1339547
> > > Total Files 1064536
> > > Total Pages 324346
> > > Total Visits 58178
> > > Total KBytes 2712883
> > >
> > > In other words, 2.7Gb in 8/9 days.
> > >
> > > I'm not sure I'd call tha
> -Original Message-
> From: Greg Copeland [mailto:[EMAIL PROTECTED]]
> Sent: 13 January 2003 20:56
> To: Robert Treat
> Cc: [EMAIL PROTECTED]; PostgresSQL Hackers Mailing List
> Subject: Re: [HACKERS] \d type queries - why not views in
> system catalog?!?
>
>
> Oh!
>
> That's an exc
Views or C-functions, I think the idea is excellent. It's the concept
that I really like.
Greg
On Mon, 2003-01-13 at 15:00, Dave Page wrote:
> > -Original Message-
> > From: Greg Copeland [mailto:[EMAIL PROTECTED]]
> > Sent: 13 January 2003 20:56
> > To: Robert Treat
> > Cc: [EMAIL PRO
You have to do it in functions because some of the \ commands use
multiple queries and logic inside the C code.
Robert Treat
On Mon, 2003-01-13 at 16:42, Greg Copeland wrote:
> Views or C-functions, I think the idea is excellent. It's the concept
> that I really like.
>
> Greg
>
>
> On Mon,
Robert Treat kirjutas T, 14.01.2003 kell 01:50:
> One of the reasons that this
> was not feasible in the past was that we needed functions that could
> return multiple rows and columns easily. Now that we have that in 7.3,
> it might be worth revisiting.
Also, we have schemas now, so it would be
Often I need to remove a user and cede their permissions to someone else.
How about something like this:
DROP USER blah PERMISSIONS TO chriskl;
or maybe
GRANT ALL USER blah TO chriskl;
???
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' t
On Mon, 2003-01-13 at 21:40, Christopher Kings-Lynne wrote:
> Often I need to remove a user and cede their permissions to someone else.
> How about something like this:
>
> DROP USER blah PERMISSIONS TO chriskl;
If you check that it's a superuser doing the drop, this would be good.
However, what
> On Mon, 2003-01-13 at 21:40, Christopher Kings-Lynne wrote:
> > Often I need to remove a user and cede their permissions to
> someone else.
> > How about something like this:
> >
> > DROP USER blah PERMISSIONS TO chriskl;
>
> If you check that it's a superuser doing the drop, this would be good.
> Yeah good point...it wouldn't bother me if it were just current database,
> except that then it wouldn't be useful to use the DROP USER command. ALTER
> USER or GRANT would be better.
How do you ALTER USER ... after they've been dropped?
> BTW Rod, I now get all your emails just fine (not as a
> > Yeah good point...it wouldn't bother me if it were just current
> database,
> > except that then it wouldn't be useful to use the DROP USER
> command. ALTER
> > USER or GRANT would be better.
>
> How do you ALTER USER ... after they've been dropped?
No, I mean that we don't drop the user.
Robert Treat writes:
> One idea I've always thought would be nice would be to make full fledged
> C functions out of the \ commands and ship them with the database.
The psql meta-commands are not a nicely designed set of queries that one
would encapsulate into a public library interface. They ar
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> No, I mean that we don't drop the user. You go:
> ALTER USER chriskl COPY PERMISSIONS FROM blah;
That seems cleaner to me than the DROP thingy.
You could only easily implement this in the current database --- but
since it's not a DROP, one
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > No, I mean that we don't drop the user. You go:
> > ALTER USER chriskl COPY PERMISSIONS FROM blah;
>
> That seems cleaner to me than the DROP thingy.
>
> You could only easily implement this in the current database --- but
> since it's no
[EMAIL PROTECTED] wrote:
> Area902.Com is a Free Service provided by Hub.Org Networking Services"
>
> Because hub.org is also displaying the postgresql.org page on the same subnet,
> so the disparity should in theory be quite controllable. *If* we are going
> to keep the ads (and my vote is a st
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Robert Treat writes:
>> One idea I've always thought would be nice would be to make full fledged
>> C functions out of the \ commands and ship them with the database.
> The psql meta-commands are not a nicely designed set of queries that one
> would e
What should we do with the TODO item? Add question mark? Remove?
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Robert Treat writes:
> >> One idea I've always thought would be nice would be to make f
What about querying the information_schema?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Treat
> Sent: Tuesday, 14 January 2003 6:01 AM
> To: Greg Copeland
> Cc: Dave Page; [EMAIL PROTECTED]; PostgresSQL Hackers Mailing List
> Subjec
Jeremy,
This appears to be a bug in the database. I have been able to
reproduce. It appears that the new 'autocommit' functionality in 7.3
has a problem.
The jdbc driver is essentially issuing the following sql in your example:
set autocommit = off; -- result of the setAutoCommit(false) call
42 matches
Mail list logo