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: n
> > 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 entirel
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 o
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 pr
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
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
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
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) ret
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', 1
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 h
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 to
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
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
inv
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 arbit
> > 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
> > 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, b
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 displa
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
inv
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
> -
"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 <[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?
> IS
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 arr
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:
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 i
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 h
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 tha
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 co
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 c
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
definitions/indexes.
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:
> > | s
>
>
> --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) bec
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,
practica
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 e
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 broadcast)
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 relin
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 c
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
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 cod
--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 m
mlw wrote:
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
ye
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:
> > -Origi
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 Postgre
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 woul
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 it
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 t
> > 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,
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 st
* Backend should pass its version number, database encoding, default
client encoding, and possibly other data (any ideas?) to frontend during
startup, to avoid need for explicit queries to get this info. We could
also consider eliminating SET commands sent by libpq in favor of adding
variable set
48 matches
Mail list logo
