Dave Page wrote:
I don't know about JDBC, but ODBC could use it, and it would save a heck
of a lot of pain in apps like pgAdmin that need to figure out if a column
in an arbitrary resultset might be updateable.
At the moment there is some nasty code in pgAdmin II that attempts to
parse the SQL
I'm still unclear on exactly what your needs are. In the first place,
are you expecting to obtain data from arbitrary SELECT statements, or
only from statements of the form SELECT * FROM single_table? You've
also been confusing as to whether you want transparency of views (ie,
does a
Hi,
Would it be cool to decide on the version numbering of our next release
like this:
+ If it looks like we'll have Win32 and/or PITR recovery in time for
the next release, we call it PostgreSQL 8.0
+ If not, we call it 7.4
Wouldn't a new FE/BE protocol be a better reason to call
Justin Clift wrote:
Hi everyone,
Thinking about the numbering further.
Would it be cool to decide on the version numbering of our next
release like this:
+ If it looks like we'll have Win32 and/or PITR recovery in time for
the next release, we call it PostgreSQL 8.0
+ If not, we call
I was at a client office reviewing some code. They use MSSQL and I
noticed that:
select * from table where field = 'blah';
gave the same results as:
select * from table where field = 'BLah';
I was shocked. (a) because I know a lot of my code could be easier to
write, and (b) that their code
On Wed, 2003-03-12 at 01:26, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Would it be cool to decide on the version numbering of our next release
like this:
+ If it looks like we'll have Win32 and/or PITR recovery in time for
the next release, we call it PostgreSQL 8.0
This may be problematic in the future if we change attrelid, attnum.
My preference would be to be able to query the backend for the
information if I need it. It is rarely required.
ie give me the meta data for the last resultset.
Dave
On Wed, 2003-03-12 at 09:49, Dave Page wrote:
mlw wrote:
snip
So, if the decision is to go with an 8.0, what would you guys say to
having a roll call about stuff that is possible and practical and
really design PostgreSQL 8.0 as something fundimentally newer than
7.x. 8.0 could get the project some hype. It has been 7x for so many
years.
--le 12/03/2003 09:03 -0500, mlw écrivait :
| I was at a client office reviewing some code. They use MSSQL and I
| noticed that:
|
| select * from table where field = 'blah';
| gave the same results as:
| select * from table where field = 'BLah';
|
| I was shocked. (a) because I know a lot of
On Wed, 2003-03-12 at 09:03, mlw wrote:
I was at a client office reviewing some code. They use MSSQL and I
noticed that:
select * from table where field = 'blah';
gave the same results as:
select * from table where field = 'BLah';
I was shocked. (a) because I know a lot of my code could
On Wednesday 12 March 2003 09:55, Robert Treat wrote:
Personally I think Justin is a little off base with his criteria, since
I see the FE/BE protocol changes as the real differentiator between an
8.0 and 7.4. Everyone is effected by a FE/BE protocol change, not nearly
so many are effected by
Lamar Owen [EMAIL PROTECTED] writes:
FWIW, the 6.4 protocol change didn't force a move from 6.3.2 to 7.0.
True, but that was a much smaller change than what we're contemplating
here. AFAIR, those changes did not affect the majority of applications
--- they only needed to relink with a newer
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
FWIW, the 6.4 protocol change didn't force a move from 6.3.2 to 7.0.
True, but that was a much smaller change than what we're contemplating
here. AFAIR, those changes did not affect the majority of applications
--- they only needed to relink
Justin Clift writes:
+ If it looks like we'll have Win32 and/or PITR recovery in time for
the next release, we call it PostgreSQL 8.0
To me, those sound fairly unspectacular as reasons for 8.0.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
Barry Lind [EMAIL PROTECTED] writes:
One addition I would personally like to see (it comes up in my apps
code) is the ability to detect wheather the server is big endian or
little endian. When using binary cursors this is necessary in order to
read int data.
Actually, my hope is to
I think the first thing we should do about that is to define what are the
reasons for a major version change. The way this discussion is being taken
will not take us anywhere... is just too much about personal opinions.
Anyway, for most users a win32 port is not a big deal (after all,
--le 12/03/2003 09:03 -0500, mlw écrivait :
| I was at a client office reviewing some code. They use MSSQL and I |
noticed that:
|
| select * from table where field = 'blah';
| gave the same results as:
| select * from table where field = 'BLah';
|
| I was shocked. (a) because I
On Wed, 2003-03-12 at 12:57, [EMAIL PROTECTED] wrote:
--le 12/03/2003 09:03 -0500, mlw écrivait :
| I was at a client office reviewing some code. They use MSSQL and I |
noticed that:
|
| select * from table where field = 'blah';
| gave the same results as:
| select * from
I know that the MSSQL code works because the default collation sequence
for character fields is case-insensitive. You can change it for each
field independantly to be case sensitive, local specific, etc. I'm not
sure if PG supports a collation sequence attribute on column
Peter Eisentraut writes:
Dave Page writes:
Well what I *really* need has been made quite clear in other posts,
but,
when I say resultset in the same sentence as pgAdmin, I'm referring
to
the ability to enter an arbitrary SQL query, have the results
displayed
in a grid, which can then
On Wed, 2003-03-12 at 13:35, Dwayne Miller wrote:
I know that the MSSQL code works because the default collation sequence
for character fields is case-insensitive. You can change it for each
field independantly to be case sensitive, local specific, etc. I'm not
sure if PG supports a
Tom Lane wrote:
But I think I like better the notion of extending my bound-together-
ANYARRAY-and-ANYELEMENT proposal,
http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php
Suppose that we do that, and then further say that ANYARRAY or
ANYELEMENT appearing as the return type implies
Joe Conway [EMAIL PROTECTED] writes:
+ * If ANY, ANYARRAY, or ANYELEMENT is used for a function's arguments or
+ * return type, make sure the runtime types are consistent with
+ * each other. The argument consistency rules are like so:
+ *
+ * 1) All arguments declared ANY should have
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
+ * If ANY, ANYARRAY, or ANYELEMENT is used for a function's arguments or
+ * return type, make sure the runtime types are consistent with
+ * each other. The argument consistency rules are like so:
Hmm. I don't see why we should drag ANY
Deepak Bhole of Red Hat just pointed out to me a failure that he got
after some 7.3 stress testing:
[ [EMAIL PROTECTED]*()''| \final_db\n,.;:' ]=# SELECT n.nspname, p.proname,
o.oprcode::oid FROM pg_operator o, pg_proc p, pg_namespace n WHERE
o.oid=270447::oid AND p.oid=o.oprcode::oid AND
Tom Lane wrote:
Another approach is to try to fix pg_statistic to avoid the problem by
not doing I/O conversions. For scalar datatypes (those that have
associated array types) it'd be probably be feasible to store the
histogram and most-common-value arrays as arrays of the datatype itself,
not
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
I am not sure what to do about columns that
have datatypes without matching array types, though (that would include
array columns and domains, IIRC). Maybe use array of bytea to hold the
internal representation of the type?
ISTM that the
Marc G. Fournier [EMAIL PROTECTED] writes:
Personally ... as long as a v8.x client can talk to a v7.x backend, you
have my vote ... I'm more apt to upgrade my clients before my servers
anyway ...
Surely that's not true for a production environment. You have one database but
potentially
Joe Conway writes:
2) Implement the following new builtin functions
array_push(anyarray, anyelement) returns anyarray
array_pop(anyarray) returns anyelement
array_subscript(anyarray, int) yields anyelement
singleton_array(anyelement) returns anyarray
- any
Tom Lane wrote:
I think that we can actually get away (from an implementation point of
view) with a column containing arrays of different base types; array_out
will still work AFAIR. It's an interesting question though how such a
column could reasonably be declared. This ties into your recent
One addition I would personally like to see (it comes up in my apps
code) is the ability to detect wheather the server is big endian or
little endian. When using binary cursors this is necessary in order to
read int data.
Actually, my hope is to eliminate that business entirely by
Tom Lane wrote:
I think that we can actually get away (from an implementation point of
view) with a column containing arrays of different base types; array_out
will still work AFAIR. It's an interesting question though how such a
column could reasonably be declared. This ties into your recent
mlw wrote:
...
select * from table where field = 'blah';
gave the same results as:
select * from table where field = 'BLah';
I was shocked. (a) because I know a lot of my code could be easier to
write
...
select * from table where field ILIKE 'blAH'; -- ;-)
is almost as easy :-)
PS: no,
Hi Gang
I can sense that I'm _really_ close to getting docbook working, but
not quite there yet. I'm hoping somebody can tell me where I'm
screwing up !
I'm on a Red Hat Linux 7.3 system. Although I do have openjade
installed I was finding it difficult to figure out where to point
stylesheets
When I create a new table with a serial column, the first row defaults to
inserting '1'.
If I delete all the rows from the table and want to reset the sequence, I
can't:
ERROR: users_health_types_type_id_seq.setval: value 0 is out of bounds
(1,9223372036854775807)
How do I set the sequence to
Christopher Kings-Lynne wrote:
How do I set the sequence to have next value = 1? Surely the bounds should
begin at zero?
No; see:
http://www.us.postgresql.org/users-lounge/docs/7.3/postgres/functions-sequence.html
Notice the is_called flag. I think this does what you want:
SELECT setval('foo',
Peter Eisentraut wrote:
Joe Conway writes:
2) Implement the following new builtin functions
array_push(anyarray, anyelement) returns anyarray
array_pop(anyarray) returns anyelement
array_subscript(anyarray, int) yields anyelement
singleton_array(anyelement) returns
Phew .. after some more struggling with docbook I think I finally
managed to get it working. Posting here to help other folks googling
through usenet archives.
My problem was that I had DOCBOOKSTYLE set to /usr/local/share/sgml -
the directory which contained the catalog file. However, inspite
Greg Stark [EMAIL PROTECTED] writes:
It's upgrading the database that's likely to be the driving motivation
for new sql or storage features. People usually don't get excited
about upgrading the client libraries :)
Usually not. This cycle might be different though, if we are able to
finish the
Joe Conway [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Create an array support package on gborg if you like, but I feel this
should not be in the mainline.
Arrays *do* have a place, and they are supported in SQL99+.
FWIW, I'm with Joe on this one. Arrays have their uses; and it's not
Greg Stark kirjutas K, 12.03.2003 kell 07:10:
Marc G. Fournier [EMAIL PROTECTED] writes:
Personally ... as long as a v8.x client can talk to a v7.x backend, you
have my vote ... I'm more apt to upgrade my clients before my servers
anyway ...
Surely that's not true for a production
Tom Lane kirjutas K, 12.03.2003 kell 18:19:
Barry Lind [EMAIL PROTECTED] writes:
One addition I would personally like to see (it comes up in my apps
code) is the ability to detect wheather the server is big endian or
little endian. When using binary cursors this is necessary in order to
One addition I would personally like to see (it comes up in my
apps code) is the ability to detect wheather the server is big
endian or little endian. When using binary cursors this is
necessary in order to read int data.
Actually, my hope is to eliminate that business entirely by
Hannu Krosing wrote:
Tom Lane kirjutas K, 12.03.2003 kell 18:19:
Actually, my hope is to eliminate that business entirely by
standardizing the on-the-wire representation for binary data; note the
reference to send/receive routines in the original message. For integer
data this is simple enough:
Peter Eisentraut wrote:
(B
(B Dave Page writes:
(B
(B Well what I *really* need has been made quite clear in other
(B posts, but, when I say resultset in the same sentence as
(B pgAdmin, I'm referring to the ability to enter an arbitrary
(B SQL query, have the results displayed in a
I suggested using names to Tom for this reason, but he preferred to use
attrelid/attnum.
Oh, and what happenned to the attlognum idea? If something that needs
it is going to be implemented the column should probably be added now
and used instead of attnum.
Wll, it'd be nice, but I
On Wed, 2003-03-12 at 20:45, Hiroshi Inoue wrote:
Peter Eisentraut wrote:
Dave Page writes:
Well what I *really* need has been made quite clear in other
posts, but, when I say resultset in the same sentence as
pgAdmin, I'm referring to the ability to enter an arbitrary
SQL
47 matches
Mail list logo
