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 the above needs
-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
- 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 TYPE EmpRec IS RECORD (
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 id NUMBER,
6
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 faster.
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
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,
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 important
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 would remove
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
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 there are
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 rehashes the
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 you slept
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 a
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
parsetree as its
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.
Anyway it's too bad
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 MOVE
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 LAST works
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 currently.
I
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, run the
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
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
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 sync'd.
So
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 have
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 simply
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
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
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
28 matches
Mail list logo
