Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
This probably has been discussed and is probably a very minor point, but consider how many more years we want to be able to use the single digit.single digit major release numbering. Assuming 1 year between major releases (7.3.0 - 7.4.0 = +- 1 year), then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to 8.0 now, then we have up until 2023. Also we have 1 more chance to skip major number: 8.x - 9.0. Imagine what features will there be in 9.0 that is ground-breaking enough. Because after that, we don't have any more major number to jump into without going into 2 digits. I personally don't see the major number as a very magical thing. Look at Linux for example. People still see 2.6 as very different/ahead compared to 2.4... -- dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Advice regarding configuration parameters
Some very good suggestions where made here. What happens next? Will this end up in a TODO list where someone can claim the task (I'm trying to learn how the process works) ? Kind regards, Thomas Hallgren - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Joe Conway [EMAIL PROTECTED] Cc: Peter Eisentraut [EMAIL PROTECTED]; Thomas Hallgren [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, February 06, 2004 19:15 Subject: Re: [HACKERS] Advice regarding configuration parameters Joe Conway [EMAIL PROTECTED] writes: I like it. I wonder if we ought to have a way to register valid classes? Maybe a new guc variable in the form of a list of valid classes. So something like: There are some order-of-processing issues there, but maybe. Another possibility is that after a shlib has finished registering its variables, it could look for remaining placeholders matching its prefix and issue WARNINGs about 'em (it can't realistically ERROR, probably, but a WARNING would surely help). These are actually orthogonal checks since one addresses the class part and the other the individual variable. And we'd have to think a little about how to handle variable values that are discovered to be erroneous when we try to assign them to the variable --- probably we can just drop them, but does that make the semantics weird at all? Maybe we can require a default value as a parameter to add_guc_variable() and use that? Well, the new GUC variable struct would include a default by definition, and presumably that value would bubble up to replace any values that are found illegal. The sort of semantic funny I am thinking of is like this: * postgresql.conf contains pljava::var = somegoodvalue * ALTER DATABASE SET supplies pljava::var = somebadvalue For builtin variables the ALTER DATABASE value would be rejected on sight and the end result would be that the variable contains 'somegoodvalue'. However if we don't yet know the variable at backend startup, 'somebadvalue' will replace 'somegoodvalue' completely, and then when the PL actually gets loaded it will get thrown away. End result is that the variable will have whatever its hardwired default is, and not 'somegoodvalue' as one would wish. Even more surprising, a subsequent SIGHUP would make it acquire 'somegoodvalue'. This particular case could be dealt with by forcing a rescan of postgresql.conf after new variables are defined (I think we need only do so if any errors are detected in assigning values), but that will not handle everything. We don't have any way to get back overridden values from other sources such as the postmaster command line. It seems likely to me that such corner cases are sufficiently bizarre to not bother anyone, but we need to think more to make sure that there aren't any that would bother someone. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
, 05.06.2004, 10:28, David Garamond : This probably has been discussed and is probably a very minor point, but consider how many more years we want to be able to use the single digit.single digit major release numbering. Assuming 1 year between major releases (7.3.0 - 7.4.0 = +- 1 year), then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to 8.0 now, then we have up until 2023. Also we have 1 more chance to skip major number: 8.x - 9.0. Imagine what features will there be in 9.0 that is ground-breaking enough. Because after that, we don't have any more major number to jump into without going into 2 digits. What's the problem with 7.10? -- Markus Bertheau [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
From: David GaramondSent: Sat 6/5/2004 9:28 AMCc: postgresql advocacy; [EMAIL PROTECTED]Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ? Assuming 1 year between major releases (7.3.0 - 7.4.0 = +- 1 year), then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to 8.0 now, then we have up until 2023. Hi Dave, I might be missing the point, but why can't we go to double figures? MS Office has, HP-UX has, OS-X, Norton AV has, Madrake Linux has... Regards, Dave
[HACKERS] I/O support for composite types
There's just one thing left to do to make composite types useful as
table columns: we have to support I/O of composite values. (Without
this, pg_dump would fail to work on such columns, rendering them not
very useful in the real world.) This means we have to hammer out a
definition for what the external representation is. Here are my
thoughts on the subject.
Textual representation:
I am inclined to define this similarly to the representation for arrays;
however, we need to allow for NULLs. I suggest
{item,item,item}
The separator is always comma (it can't be type-specific since the items
might have different types). Backslashes and double quotes can be used
in the usual ways to quote characters in the item strings. If an item
string is completely empty it is taken as NULL; to write an actual
empty-string value, you must write . There is an ambiguity whether
'{}' represents a zero-column row or a one-column row containing a NULL,
but I don't think this is a problem since the input converter will
always know how many columns it is expecting.
There are a couple of fine points of the array I/O behavior that I think
we should not emulate. One is that leading whitespace in an item string
is discarded. This seems inconsistent, mainly because trailing
whitespace isn't discarded. In the cases where it really makes sense to
discard whitespace (namely numeric datatypes), the underlying datatype's
input converter can do that just fine, and so I suggest that the record
converter itself should not discard whitespace. It seems OK to ignore
whitespace before and after the outer braces, however.
The other fine point has to do with double quoting. In the array code,
{abcd}
is legal input representing an item 'abcd'. I think it would be more
consistent with usual SQL conventions to treat it as meaning 'abcd',
that is a doubled double quote within double quotes should represent a
double quote not nothing. Anyone have a strong feeling one way or the
other?
(In the long run we might want to think about making these same changes
in array_in, but that's a can of worms I don't wish to open today.)
Binary representation:
This seems relatively easy. I propose we send number of fields (int4)
followed by, for each field: type oid (sizeof(Oid)), data length (int4),
data according to the binary representation of the field datatype.
The field count and type oids are not strictly necessary but seem like
a good idea for error-checking purposes.
Infrastructure changes:
record_out/record_send can extract the needed type info right from the
Datum, but record_in/record_recv really need to be told what data type
to expect, and the current call conventions for input converters don't
pass them any useful information. I propose that we adjust the present
definitions so that the second argument passed to I/O conversion
routines, rather than being always pg_type.typelem, is defined as
if pg_type.typtype is 'c' then pg_type.oid else pg_type.typelem.
That is, for composite types we'll pass the type's own OID in place of
typelem.
This does not affect I/O routines for user-defined types, since there
are no user-defined I/O routines for composite types. It could break
any user-written code that calls I/O routines, if it's been hard-wired
to pass typelem instead of using one of the support routines like
getTypeInputInfo() or get_type_io_data() to collect the parameters to
pass. By my count there are about a dozen places in the backend code
that will need to be fixed to use one of these routines instead of
having a hard-wired typelem reference.
An alternative definition that might be more useful in the long run is
to define the second parameter as
if pg_type.typelem is not zero then pg_type.typelem else pg_type.oid.
In other words, for everything *except* arrays we'd pass the type OID.
This would allow I/O routines to be written to support multiple
datatypes. However there seems a larger chance of breaking things if
we do this, and I'm also fuzzy on which OID to pass for domain types.
So I'm inclined to keep it conservative for now, and change the
behavior only for composite types.
Comments, objections, better ideas?
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
Andrew Dunstan wrote: But following through a cycle or two in the archives provides ample evidence for the 'laid-back' model used here. It's ready when it's ready. We try to schedule, but the schedules are pretty flexible. And while most discussion happens here on [HACKERS], not all of it does. Some happens on IRC, some in [CORE], and some by telephone. And it's been that way for a while. PostgreSQL is not a 'release early, release often' project. And that's OK. If it were true that June 1 was the expected Beta data, then perhaps that should be in the FAQ too, as a counterweight to the gratuitously patronising advice which, had I followed it, might have resulted in my not making a number of contributions. But it is not true. I have already pointed out what Tom said on March 31: There's not really a plan at the moment, but I had June in the back of my head as a good time. IOW, June was a possible month, nothing was settled, certainly not a definite day. So ISTM your premise is simply wrong. All I have asked for is a) reasonable clarity and b) reasonable notice. I do not see that either of those conflict with being laid-back or anything else above. I believe the decision for June 1 was made around May 1. I participated in the discussion. Should we have made that final decision sooner? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] I/O support for composite types
Tom Lane wrote:
I am inclined to define this similarly to the representation for arrays;
however, we need to allow for NULLs. I suggest
{item,item,item}
The separator is always comma (it can't be type-specific since the items
might have different types). Backslashes and double quotes can be used
in the usual ways to quote characters in the item strings. If an item
string is completely empty it is taken as NULL; to write an actual
empty-string value, you must write . There is an ambiguity whether
'{}' represents a zero-column row or a one-column row containing a NULL,
but I don't think this is a problem since the input converter will
always know how many columns it is expecting.
There are a couple of fine points of the array I/O behavior that I think
we should not emulate. One is that leading whitespace in an item string
is discarded. This seems inconsistent, mainly because trailing
whitespace isn't discarded. In the cases where it really makes sense to
discard whitespace (namely numeric datatypes), the underlying datatype's
input converter can do that just fine, and so I suggest that the record
converter itself should not discard whitespace. It seems OK to ignore
whitespace before and after the outer braces, however.
The other fine point has to do with double quoting. In the array code,
{abcd}
is legal input representing an item 'abcd'. I think it would be more
consistent with usual SQL conventions to treat it as meaning 'abcd',
that is a doubled double quote within double quotes should represent a
double quote not nothing. Anyone have a strong feeling one way or the
other?
Why not use standard C semantics for the textual representation with
your addition that empty items are NULL? It becomes fairly stright
forward, IMO highly readable, and the rules to define both arrays and
complex types are well known and documented.
Here's an array of two composite elements of the same type. The last two
items of the second element is NULL. The type is {int, double, string, char}
{
{12, 123.4, some string with \a qouted string\ inside of it, 'c'},
{13, -3.2,,}
}
This will also allow you to distinguish strings from identifiers. That
might prove extremely important if you ever plan to serialize self
referencing structures (a structure could then represent itself as
ref_oid or something and thereby refer to itself).
Kind regards,
Thomas Hallgren
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] I/O support for composite types
Thomas Hallgren [EMAIL PROTECTED] writes: Why not use standard C semantics for the textual representation with your addition that empty items are NULL? This isn't C, it's SQL; and I think the array I/O representation is a closer precedent for us than the C standard. In any case, how much of C syntax are you proposing to emulate exactly? Comments? Backslashed newlines? Joining of adjacent double-quoted strings? Conversion of octal and hex integer constants (and what about L, U, LL, etc suffixes)? There's a lot more stuff there than meets the eye, and most of it isn't something I want to code. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] I/O support for composite types
Composite types will work recursively, right?
That is a composite type inside of a composite type column?
Does the SQL dot syntax support this nested referencing?
Or are we only allowing one level.
Why not just use the syntax of the insert values with parens?
insert into tble values (...);
is very familiar so the corresponding:
insert into table values ( 'xxx', ('yyy', 123), 456 );
is also easy to understand and remember: a row is being inserted.
Is there a specific reason why you want curly brackets?
I have not been following this much to my chagrin.
On Sat, Jun 05, 2004 at 12:57:27PM -0400, Tom Lane wrote:
good stuff deleted...
There are a couple of fine points of the array I/O behavior that I think
we should not emulate. One is that leading whitespace in an item string
is discarded. This seems inconsistent, mainly because trailing
whitespace isn't discarded. In the cases where it really makes sense to
discard whitespace (namely numeric datatypes), the underlying datatype's
input converter can do that just fine, and so I suggest that the record
converter itself should not discard whitespace. It seems OK to ignore
whitespace before and after the outer braces, however.
If the whitespace is inside of the item, do not discard it; let the
underlying type deal with it. If the white space is outside of the
item, ignore it. I think you probably meant this, but just to be sure.
{ item number one } == input_text( item number one )
more good stuff deleted
Comments, objections, better ideas?
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--elein
[EMAIL PROTECTED]Varlena, LLCwww.varlena.com
PostgreSQL Consulting, Support Training
PostgreSQL General Bits http://www.varlena.com/GeneralBits/
=
I have always depended on the [QA] of strangers.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
On Sat, 5 Jun 2004, Andrew Dunstan wrote: All I have asked for is a) reasonable clarity and b) reasonable notice. I do not see that either of those conflict with being laid-back or anything else above. Something we definitely will work on, in both cases ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] I/O support for composite types
Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: Why not use standard C semantics for the textual representation with your addition that empty items are NULL? This isn't C, it's SQL; and I think the array I/O representation is a closer precedent for us than the C standard. In any case, how much of C syntax are you proposing to emulate exactly? Comments? Backslashed newlines? Joining of adjacent double-quoted strings? Conversion of octal and hex integer constants (and what about L, U, LL, etc suffixes)? There's a lot more stuff there than meets the eye, and most of it isn't something I want to code. I'm not proposing a full C parser implementation :-) Just static data initializer part. To answer how much of the C syntax: Comments, no. SQL has a standard for comments that doesn't conflict with C semantics for data initializers. Joining of adjacent double-quoted strings. Yes, of course. That's what you already do for arrays today. Without this, it will be hard to write long strings in a readable way. Conversion of backslashed newlines, octal and integer constants within strings, yes, why not? The issue of non-printables needs to be addressed somehow. What do you propose? Regarding the L, U, LL suffixes, depends in what way do you plan to tackle different character sets. Perhaps UTF-8 with unicode escapes would be better. Some mechanism i needed, that's for sure. Kind regards, Thomas Hallgren ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
Bruce Momjian wrote: I believe the decision for June 1 was made around May 1. I participated in the discussion. Should we have made that final decision sooner? No, I think that was the right time to make a decision. Before that things were in a great state of flux. My suggestion is that there should be some minimum time (I suggested 6 weeks to 2 months) between when the decision is made/announced and the actual freeze date. In the present case we would have probably have ended up with a date very like what we now have, but without the June 1 false start, which many (including me) felt tried to set the date too early and gave insufficient notice to those who wanted to make the cut. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Why hash indexes suck
Dann Corbit [EMAIL PROTECTED] writes: There seems to be something seriously defective with hash indexes in old versions of PostgreSQL. They still suck; I'm not aware of any situation where I'd recommend hash over btree indexes in Postgres. I think we have fixed the hash indexes' deadlock problems as of 7.4, but there's still no real performance advantage. I just had an epiphany as to the probable reason why the performance sucks. It's this: the hash bucket size is the same as the page size (ie, 8K). This means that if you have only one or a few items per bucket, the information density is awful, and you lose big on I/O requirements compared to a btree index. On the other hand, if you have enough items per bucket to make the storage density competitive, you will be doing linear searches through dozens if not hundreds of items that are all in the same bucket, and you lose on CPU time (compared to btree which can do binary search to find an item within a page). It would probably be interesting to look into making the hash bucket size be just a fraction of a page, with the intent of having no more than a couple dozen items per bucket. I'm not sure what the implications would be for intra-page storage management or index locking conventions, but offhand it seems like there wouldn't be any insurmountable problems. I'm not planning on doing this myself, just throwing it out as a possible TODO item for anyone who's convinced that hash indexes ought to work better than they do. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
Dave Page wrote: From: David Garamond Sent: Sat 6/5/2004 9:28 AM Cc: postgresql advocacy; [EMAIL PROTECTED] Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ? Assuming 1 year between major releases (7.3.0 - 7.4.0 = +- 1 year), then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to 8.0 now, then we have up until 2023. Hi Dave, I might be missing the point, but why can't we go to double figures? MS Office has, HP-UX has, OS-X, Norton AV has, Madrake Linux has... Of course we can, I didn't say we can't. But double digits are sometimes undesirable because it can break some things. For example, a simple shell or Perl script might try to compare the version of two data directories by comparing the content of PG_VERSION stringwise. It then concludes that 7.10 is smaller than 7.4. Granted, the script itself is faulty, but since some other OS projects (like Ruby, with the same x.y.z numbering) do guarantee they never will have double digits in version number component than people might think the same too and thus the habit of stringwise version comparison continues. -- dave ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] I/O support for composite types
elein [EMAIL PROTECTED] writes:
Composite types will work recursively, right?
That is a composite type inside of a composite type column?
You can have that, but I'm not intending that the I/O syntax be
explicitly aware of it. A composite type field would just be an
item (and hence would have to be suitably quoted). So it would
look something like
{somecolumn,{anothercolumn,\a quoted column\},column3}
if we go with the syntax I originally suggested.
Note that just as we offer ARRAY[] to avoid having to write this sort
of thing in SQL statements, we offer ROW() so you can synthesize
composite values without actually having to write this junk. I see
this mainly as a dump/reload representation, so I'm not too worried
about whether complex cases can be written simply.
Does the SQL dot syntax support this nested referencing?
Or are we only allowing one level.
You have to parenthesize to avoid ambiguity against the normal
table.field notation, but beyond that it works. For instance
(this is a real example with CVS tip + error check removed):
regression=# create type complex as (r float8, i float8);
CREATE TYPE
regression=# create table foo (c complex);
CREATE TABLE
regression=# insert into foo values(row(1.1, 2.2));
INSERT 154998 1
-- this doesn't work yet:
regression=# select c from foo f;
ERROR: output of composite types not implemented yet
-- here is the ambiguity problem:
regression=# select c.r from foo f;
NOTICE: adding missing FROM-clause entry for table c
ERROR: column c.r does not exist
-- which you can fix like this:
regression=# select (c).r, (f.c).i from foo f;
r | i
-+-
1.1 | 2.2
(1 row)
-- nested types work about like you'd expect:
regression=# create type quad as (c1 complex, c2 complex);
CREATE TYPE
regression=# create table bar (q quad);
CREATE TABLE
regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4)));
INSERT 155006 1
regression=# select (q).c2.r from bar;
r
-
3.3
(1 row)
Why not just use the syntax of the insert values with parens?
insert into tble values (...);
is very familiar so the corresponding:
insert into table values ( 'xxx', ('yyy', 123), 456 );
is also easy to understand and remember: a row is being inserted.
I don't particularly care one way or the other about parens versus
braces; anyone else have an opinion on that?
However, I do want to follow the array syntax to the extent of using
double not single quotes for quoting items. Otherwise you've got a mess
when you do try to write one of these things as a SQL literal.
For instance, instead of
'{1.1,2.2}'::complex
you'd have to write
'{\'1.1\',\'2.2\'}'::complex
which is just painful. (In this particular example of course the inner
quotes could just be dropped entirely, but with textual fields they
would often be necessary.)
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Why hash indexes suck
Sailesh Krishnamurthy [EMAIL PROTECTED] writes: This is probably a crazy idea, but is it possible to organize the data in a page of a hash bucket as a binary tree ? Only if you want to require a hash opclass to supply ordering operators, which sort of defeats the purpose I think. Hash is only supposed to need equality not ordering. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
David Garamond [EMAIL PROTECTED] writes: Granted, the script itself is faulty, but since some other OS projects (like Ruby, with the same x.y.z numbering) do guarantee they never will have double digits in version number component Oh? What's their plan for the release after 9.9.9? In practice, non-broken bits of code don't make such an assumption, as there have always been lots of projects with double-digit version components. A quick grep for locally-installed packages finds autoconf-2.53.tar.gz binutils-2.10.1.tar.gz bison-1.875.tar.gz cvs-1.10.7.tar.gz emacs-19.34b.tar.gz expect-5.38.tar.gz gcc-2.95.3.tar.gz gettext-0.11.5.tar.gz ghostscript-6.50.tar.gz lesstif-0.89.9.tar.gz lsof_4.47_W.tar.gz make-3.79.1.tar.gz mysql-3.23.29a-gamma.tar.gz netcat-1.10.tar.gz ntp-4.0.99k.tar.gz procmail-3.22.tar.gz sendmail.8.12.11.tar.gz tar-1.13.tar.gz IMHO trying to avoid double-digit component numbers is just silly. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
On Sat, 5 Jun 2004, Andrew Dunstan wrote: No, I think that was the right time to make a decision. Before that things were in a great state of flux. My suggestion is that there should be some minimum time (I suggested 6 weeks to 2 months) between when the decision is made/announced and the actual freeze date. In the present case we would have probably have ended up with a date very like what we now have, but without the June 1 false start, which many (including me) felt tried to set the date too early and gave insufficient notice to those who wanted to make the cut. Except, as some have already mentioned, the June 1st false start as you put it, was never a surprise ... *shrug* Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] I/O support for composite types
I wrote: regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4))); BTW, I forgot to mention that the keyword ROW is optional as long as you've got at least two items in the row expression, so the above can be simplified to regression=# insert into bar values (((1.1, 2.2), (3.3,4.4))); INSERT 155011 1 Some other examples: regression=# select (1,2)::complex; ERROR: output of composite types not implemented yet regression=# select cast ((1,2) as complex); ERROR: output of composite types not implemented yet Looking at these, it does seem like it would be natural to get back complex - (1,2) so I'll now agree with you that the I/O syntax should use parens not braces as the outer delimiters. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] I/O support for composite types
Good reason. Now I'm excited. I'll download and run tests and try to do a write up in general bits next week. cheers, elein On Sat, Jun 05, 2004 at 05:00:24PM -0400, Tom Lane wrote: I wrote: regression=# insert into bar values (row(row(1.1, 2.2), row(3.3, 4.4))); BTW, I forgot to mention that the keyword ROW is optional as long as you've got at least two items in the row expression, so the above can be simplified to regression=# insert into bar values (((1.1, 2.2), (3.3,4.4))); INSERT 155011 1 Some other examples: regression=# select (1,2)::complex; ERROR: output of composite types not implemented yet regression=# select cast ((1,2) as complex); ERROR: output of composite types not implemented yet Looking at these, it does seem like it would be natural to get back complex - (1,2) so I'll now agree with you that the I/O syntax should use parens not braces as the outer delimiters. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] I/O support for composite types
Tom Lane wrote:
Why not just use the syntax of the insert values with parens?
insert into tble values (...);
is very familiar so the corresponding:
insert into table values ( 'xxx', ('yyy', 123), 456 );
is also easy to understand and remember: a row is being inserted.
I don't particularly care one way or the other about parens versus
braces; anyone else have an opinion on that?
My vote would be on parens. It's more coherent. Do you use braces
anywhere else?
Kind regards,
Thomas Hallgren
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
Marc G. Fournier wrote: On Sat, 5 Jun 2004, Andrew Dunstan wrote: No, I think that was the right time to make a decision. Before that things were in a great state of flux. My suggestion is that there should be some minimum time (I suggested 6 weeks to 2 months) between when the decision is made/announced and the actual freeze date. In the present case we would have probably have ended up with a date very like what we now have, but without the June 1 false start, which many (including me) felt tried to set the date too early and gave insufficient notice to those who wanted to make the cut. Except, as some have already mentioned, the June 1st false start as you put it, was never a surprise ... *shrug* We've been aropund this block already, so I'm not going to continue. If you think the process is working just fine then don't change it. I don't, but then I am not in a position to make the decisions. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why hash indexes suck
On Sat, 2004-06-05 at 13:31, Tom Lane wrote: Only if you want to require a hash opclass to supply ordering operators, which sort of defeats the purpose I think. Hash is only supposed to need equality not ordering. Is it possible to assume some kind of ordering (i.e. strcmp() the binary data of the type) as long as it's consistent? Regards, Jeff ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why hash indexes suck
Jeff Davis [EMAIL PROTECTED] writes: On Sat, 2004-06-05 at 13:31, Tom Lane wrote: Only if you want to require a hash opclass to supply ordering operators, which sort of defeats the purpose I think. Hash is only supposed to need equality not ordering. Is it possible to assume some kind of ordering (i.e. strcmp() the binary data of the type) as long as it's consistent? Not really; that would assume that equality of the datatype is the same as bitwise equality, which is not the case in general (consider -0 versus +0 in IEEE floats, or any datatype with pad bits in the struct). Some time ago we got rid of the assumption that hash should hash on all the bits without any type-specific intervention, and I don't want to reintroduce those bugs. We could safely sort on the hash value, but I'm not sure how effective that would be, considering that we're talking about values that already hashed into the same bucket --- there's likely not to be very many distinct hash values there. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4.1 release status - Turkish Locale
Nicolai Tufar [EMAIL PROTECTED] writes: Sorry for rising up old issue again but the problem still persists. And database cluster is not being created with Turkish locale I've committed the attached fix, which I believe will solve this problem. Could you test it? (Patch is against 7.4 branch) regards, tom lane binuQ5kYk0rs1.bin Description: downcase.patch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
On Saturday 05 June 2004 10:13, Andrew Dunstan wrote: Lamar Owen wrote: There is a reason I wrote the message a long time ago (that, I think, is still in the Developer's FAQ) about how to get started in PostgreSQL development. The first thing a developer should do before getting too involved in the process is to get a feel for the development culture. If it were true that June 1 was the expected Beta data, then perhaps that should be in the FAQ too, as a counterweight to the gratuitously patronising advice which, had I followed it, might have resulted in my not making a number of contributions. I'm sorry you consider the advice to be 'patronizing' : I can assure you it is not meant that way. It was written from the point of view of someone who had been around the block and had seen how things work (and in my case one who did not do it that way, and regrets it). And I don't think I ever recommended not coding while just reading mailing lists; rather, it should be a hand in hand process: you learn the code while you learn the community. All I have asked for is a) reasonable clarity and b) reasonable notice. I do not see that either of those conflict with being laid-back or anything else above. As Marc said, that is certainly something that could use work, since we have never really been clear in dates: primarily because we never have met them. Please lighten up, that's all. That's one thing I have found helps in this project, and maybe it's not something I made clear, but we are 'laid back' including a fair amount of humor. A good portion of that goes on privately; I remember ribbing Bruce a couple of cycles back with some Biblical references about the signs of the times (he was in 'let's go back through the mailing list a few weeks and pick up TODO items and patches' mode, and I commented that it must be time for beta, due to the signs of the times.). The lesson of the history of our beta 'freezes' is that the permafrost tends to be thin early in the beta cycle, and gets progressively thicker as the cycle progresses. And we have never met the early dates, as evidenced by Peter Eisentraut's desire to see us freeze in March (which obviously did not happen). And my advice is to simply get some context about the process. One gets context of the code; one should apply the same effort to getting the context of the process. With PostgreSQL the code is large and it takes considerable digging to really get into contributing mode; it takes similar amounts of digging to merge into the process. Is this a wrong thing to do? And your contributions are very appreciated, by me in particular. Fresh code ideas, properly applied, are always welcome. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
Lamar Owen wrote: Please lighten up, that's all. That's one thing I have found helps in this project, and maybe it's not something I made clear, but we are 'laid back' including a fair amount of humor. A good portion of that goes on privately; I remember ribbing Bruce a couple of cycles back with some Biblical references about the signs of the times (he was in 'let's go back through the mailing list a few weeks and pick up TODO items and patches' mode, and I commented that it must be time for beta, due to the signs of the times.). Old habits die hard - all my life I've pushed for things I care about. Still, I hope I retain a sense of humor - the other day someone asked me about the freeze date, and I said I believed that the day and month had been settled on but people were still arguing about the year ;-) cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
