Bruce Momjian wrote:
>
> Sorry to be commenting so late.
>
> We could do that CLUSTER way of making a new heap file, but we rejected
> that for DROP COLUMN, so I am not sure why we would use that for ALTER
> COLUMN. Can anyone think of a good reason?
>
> Clearly if the new data type is binary c
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > So the backends have to keep a common list of all the files they
> > touch. Admittedly, that could be a problem if it means using a bunch
> > of shared memory, and it may have additional performance implications
> > depending on the imp
On Mon, 2003-01-13 at 07:03, Kevin Brown wrote:
> I have no problem with ads being put there, but they should load at
> least as fast as the rest of the site.
Huh!?
:-)
cheers
-- vbi
--
Packages should build-depend on what they should build-depend.
-- Santiago Vila on debian-devel
Greg Copeland wrote:
> I guess I don't understand the problem. The ads are very small and
> completely innocuous. Why would anyone care? Who's complaining and
> why?
When I loaded the new site for the first time (after the ads were
placed there), the ads stalled the loading process until I simp
Kevin Brown <[EMAIL PROTECTED]> writes:
> So the backends have to keep a common list of all the files they
> touch. Admittedly, that could be a problem if it means using a bunch
> of shared memory, and it may have additional performance implications
> depending on the implementation ...
It would
Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I'm just wondering why we do not use fsync() to flush data/index
> > pages.
>
> There isn't any efficient way to do that AFAICS. The process that wants
> to do the checkpoint hasn't got any way to know just which files need to
> be sy
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Is there some reason why pg_get_constraintdef only supports Foreign Key
> > constraints?
>
> Lack of implementation effort --- the original definition/implementation
> was FK-specific, but now, as the code says,
>
> * XXX The present impl
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is there some reason why pg_get_constraintdef only supports Foreign Key
> constraints?
Lack of implementation effort --- the original definition/implementation
was FK-specific, but now, as the code says,
* XXX The present implementation onl
Is there some reason why pg_get_constraintdef only supports Foreign Key
constraints? Why not have it output ALTER TABLE commands for UNIQUE and
PRIMARY KEY constraints? That would make my life so much easier for
phpPgAdmin and also pg_dump could be simplified quite considerably...?
Chris
-
OK, how about a backend function called 'is_prepared(name)'?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Brown
> Sent: Monday, 13 January 2003 11:13 AM
> To: PostgreSQL Hackers
> Subject: Re: [HACKERS] Prepared statements question
>
Neil Conway wrote:
> On Thu, 2003-01-09 at 22:48, Christopher Kings-Lynne wrote:
> > With prepared statements being all well and good, how do I know if the query
> > has not yet been prepared in the backend? Or is this simply a situation
> > where I can't win?
>
> Try the EXECUTE; if it fails, ru
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Hiroshi Inoue wrote:
> > Are you suggesting removing FETCH LAST _and_ MOVE LAST?.
> >>
> >> Yes. Should cursors be positioned on the last row
> >> or EOF by MOVE LAST ? Anyway I see no necessity to use
> >> the standard keyword LAST
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Hiroshi Inoue wrote:
> Are you suggesting removing FETCH LAST _and_ MOVE LAST?.
>>
>> Yes. Should cursors be positioned on the last row
>> or EOF by MOVE LAST ? Anyway I see no necessity to use
>> the standard keyword LAST currently.
>>
> I think MOVE
Hiroshi Inoue wrote:
> > Are you suggesting removing FETCH LAST _and_ MOVE LAST?.
>
> Yes. Should cursors be positioned on the last row
> or EOF by MOVE LAST ? Anyway I see no necessity to use
> the standard keyword LAST currently.
>
> > I think MOVE LAST works well.
OK, so we will switch it to
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > Honestly I'm not so enthusiastic about scrollable cursors.
> > > Even though PostgreSQL provides an efficient scrollable
> > > cursor, I would use it little unless it could survive
> > > across transactions.
> > >
> > > An
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The SQL standard requires conforming implementations to provide an
> "SQL flagger" facility ...
> I think we could implement this with relatively little intrusion if we
> create an interface routine, say SQLFlagger(), which takes the entire
> parsetre
The SQL standard requires conforming implementations to provide an
"SQL flagger" facility that, in its simplest form (which is the only
required one), points out when SQL syntax features that are not in the
core SQL feature set are used. (No catalog lookup is required.) In
other words, it prints
Ian Barwick <[EMAIL PROTECTED]> writes:
> On Sunday 12 January 2003 17:55, Bruce Momjian wrote:
>> I can't say "don't use CHAR(n)" because there are valid reasons to use
>> it.
> I think what Tom is saying is "always use VARCHAR(n) unless you know
> for sure CHAR(n) is what you want, because if yo
On Sunday 12 January 2003 17:55, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> > > OK, new text is:
> >
> > I think Tom specifically wanted the notion "don't use CHAR(n), it has
> > unusual behavior" to appear prominently in the FAQ. The current text
> > simply rehashe
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, new text is:
>
> I think Tom specifically wanted the notion "don't use CHAR(n), it has
> unusual behavior" to appear prominently in the FAQ. The current text
> simply rehashes the documentation.
I can't say "don't use CHAR(n)" because th
Bruce Momjian writes:
> OK, new text is:
I think Tom specifically wanted the notion "don't use CHAR(n), it has
unusual behavior" to appear prominently in the FAQ. The current text
simply rehashes the documentation.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of br
Hiroshi Inoue wrote:
> > Honestly I'm not so enthusiastic about scrollable cursors.
> > Even though PostgreSQL provides an efficient scrollable
> > cursor, I would use it little unless it could survive
> > across transactions.
> >
> > Anyway it's too bad that FETCH LAST means FETCH ALL.
>
> I wou
Neil Conway writes:
> > On the other hand, if we do do that then (a) pg_dump output
> > becomes even less portable than it is now, and (b) upgraded databases
> > will still have OIDs, which renders the "improved storage efficiency"
> > argument a bit thin.
> Personally, I don't think (a) is that
> Honestly I'm not so enthusiastic about scrollable cursors.
> Even though PostgreSQL provides an efficient scrollable
> cursor, I would use it little unless it could survive
> across transactions.
>
> Anyway it's too bad that FETCH LAST means FETCH ALL.
I would remove LAST,
The big ones are point-in-time recovery, Win32 port, and some type of
built-in replication. Not sure on that last one, but those are the
targets. I think the TODO list shows where we are going.
---
Andreas Joseph Krogh wro
Ian Barwick wrote:
> On Sunday 12 January 2003 06:17, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Q: Why do I get strange results with a CHAR(n) field?
> > >
> > > A. Don't use CHAR(n). VARCHAR(n) has the behavior you are probably
> > > expecting; on top of which it's more compact and usually f
On Sat, 11 Jan 2003, Tom Lane wrote:
> "Mike Mascari" <[EMAIL PROTECTED]> writes:
> > From: "Tom Lane" <[EMAIL PROTECTED]>
> >> That's a rowtype variable, though, not a record variable. I believe our
> >> code will work the same as Oracle for that case.
>
> > 4 TYPE EmpRec IS RECORD (
> > 5
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Mike Mascari" <[EMAIL PROTECTED]> writes:
> > From: "Tom Lane" <[EMAIL PROTECTED]>
> >> That's a rowtype variable, though, not a record variable. I believe our
> >> code will work the same as Oracle for that case.
>
> > 4 TY
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Does a roadmap exist for 7.4, so we know what features are to be implemented?
This might be usefull for people evaluating PostgreSQL for their future
projects. Should they wait for 7.4, or should they go with a commercial db
which has the featur
On Sunday 12 January 2003 06:17, Bruce Momjian wrote:
> Tom Lane wrote:
> > Q: Why do I get strange results with a CHAR(n) field?
> >
> > A. Don't use CHAR(n). VARCHAR(n) has the behavior you are probably
> > expecting; on top of which it's more compact and usually faster.
> >
> >
> > I suppose th
30 matches
Mail list logo
