SELECT Question

Is there an easy way to write a select statement that returns me the
frist free number or any within the range of 200?
For example if 1-30, and 32-50 are occupied then i would like to fill in
the new entry with id 31.
I currently do it with a function but I was just wondering if there is a
way without it..

If I understand well, what something about

SELECT min(xxx) FROM table WHERE xxx<50

Best regards,
Lada 'Ray' Lostak
Unreal64 Develop group
http://www.orcave.com
http://www.unreal64.net

--------------------------------------------------------------------------
In the 1960s you needed the power of two C64s to get a rocket
to the moon. Now you need a machine which is a vast number
of times more powerful just to run the most popular GUI.

Thanks,
but that only gives me smallest number of the ones in use but not the
first free number.
Alex

Lada 'Ray' Lostak wrote:

Is there an easy way to write a select statement that returns me the
frist free number or any within the range of 200?
For example if 1-30, and 32-50 are occupied then i would like to fill in
the new entry with id 31.
I currently do it with a function but I was just wondering if there is a
way without it..

If I understand well, what something about

SELECT min(xxx) FROM table WHERE xxx<50

After I sent it, I saw I understand bad... Just woke up... Sorry :)

I personally think, you need small procedure do to that, because you want to
perform condition 'min(xxx)' on "unexisting" columns.

R.

yes i am doing it that way now, but though there may be another way ...
more out of curiosity

thanks anyway

Lada 'Ray' Lostak wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Thursday 20 November 2003 08:32 schrieben Sie:

Is there an easy way to write a select statement that returns me the
frist free number or any within the range of 200?

As long as the set of numbers is not too big, the following might work:

CREATE TABLE legal_numbers ( num int );
INSERT INTO into legal_numbers VALUES ( 1 );
... do this with values from 1 to 200;

You can create this table once and for all.
Now the select is rather simple:

SELECT
min(num)
FROM
legal_numbers
WHERE
num not in ( SELECT id FROM other_table )
;

Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
info@klawitter.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/vIha1Xdt0HKSwgYRAtGbAJ4xR+Naws0vHugt40GH+BJYY/3bAwCdG7t6
2ijqnA8Fm5Z8h4Zhw5H7p3s=
=xsBO
-----END PGP SIGNATURE-----

On Thu, 20 Nov 2003, Alex wrote:

Is there an easy way to write a select statement that returns me the
frist free number or any within the range of 200?
For example if 1-30, and 32-50 are occupied then i would like to fill in
the new entry with id 31.

If you had a table with an id column and 200 rows 1-200 you could do

SELECT MIN(idtab.id) FROM idtab LEFT JOIN realtab ON (idtab.id =
realtab.id AND realtab.id IS NULL)

A useful generic function would be one something like range(min,max) that
would return a set of rows so you wouldn't have to actually have a table.

Kris Jurka

On Thu, 20 Nov 2003 16:52:37 +0900, Alex <alex@meerkatsoft.com> wrote:

Is there an easy way to write a select statement that returns me the
frist free number or any within the range of 200?
For example if 1-30, and 32-50 are occupied then i would like to fill in
the new entry with id 31.

Fortunately this is not the performance mailing list :-)

First free number:
SELECT max(t1.id) + 1
FROM t AS t1 INNER JOIN t AS t2
ON (t1.id < 200 AND t1.id < t2.id AND t2.id <= 200)
GROUP BY t2.id
HAVING max(t1.id) + 1 < t2.id
ORDER BY t2.id
LIMIT 1;

Make sure that there is always a row with id=0 and a row with id=200.

Any free number:
SELECT id - 1
FROM t
WHERE 1 < id AND id <= 200
AND NOT EXISTS (SELECT * FROM t AS t2 WHERE t2.id = t.id - 1)
LIMIT 1;

Always having a row with id=200 helps avoid unwanted corner cases.

One more:
SELECT coalesce(max(id), 0) + 1
FROM t
WHERE id <= 200
AND id = (SELECT count(*) FROM t AS t2 WHERE t2.id <= t.id);

This should work without any dummy rows. And it will not work, if id
is not unique or there is any row with id < 1.

Servus
Manfred

Kris Jurka wrote:

A useful generic function would be one something like range(min,max) that
would return a set of rows so you wouldn't have to actually have a table.

You mean like this?

CREATE OR REPLACE FUNCTION test(int,int) RETURNS SETOF int AS '
BEGIN
FOR i IN $1..$2 LOOP
RETURN NEXT i;
END LOOP;
RETURN;
END;
' LANGUAGE 'plpgsql' STRICT IMMUTABLE;

regression=# select * from test(4, 8);
test
------
4
5
6
7
8
(5 rows)

HTH,

Joe

Joe Conway <mail@joeconway.com> writes:

Kris Jurka wrote:

A useful generic function would be one something like range(min,max) that
would return a set of rows so you wouldn't have to actually have a table.

You mean like this?

CREATE OR REPLACE FUNCTION test(int,int) RETURNS SETOF int AS '
BEGIN
FOR i IN $1..$2 LOOP
RETURN NEXT i;
END LOOP;
RETURN;
END;
' LANGUAGE 'plpgsql' STRICT IMMUTABLE;

I was thinking of proposing that we provide something just about like
that as a standard function (written in C, not in plpgsql, so that it
would be available whether or not you'd installed plpgsql). There are
some places in the information_schema that desperately need it ---
right now, the value of FUNC_MAX_ARGS is effectively hard-wired into
some of the information_schema views, which means they are broken if
one changes that #define. We could fix this if we had a function like
the above and exported FUNC_MAX_ARGS as a read-only GUC variable.

regards, tom lane

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

CREATE OR REPLACE FUNCTION test(int,int) RETURNS SETOF int AS '
BEGIN
FOR i IN $1..$2 LOOP
RETURN NEXT i;
END LOOP;
RETURN;
END;
' LANGUAGE 'plpgsql' STRICT IMMUTABLE;

I was thinking of proposing that we provide something just about like
that as a standard function (written in C, not in plpgsql, so that it
would be available whether or not you'd installed plpgsql). There are
some places in the information_schema that desperately need it ---
right now, the value of FUNC_MAX_ARGS is effectively hard-wired into
some of the information_schema views, which means they are broken if
one changes that #define. We could fix this if we had a function like
the above and exported FUNC_MAX_ARGS as a read-only GUC variable.

I've been really busy on other-than-postgres stuff lately, but I'm
planning to carve out time next week to start doing some 7.5
development. I'll take this one if you want.

Joe

All,
thanks for the many suggestions
Alex

Manfred Koizar wrote:

Tom Lane wrote:

I was thinking of proposing that we provide something just about like
that as a standard function (written in C, not in plpgsql, so that it
would be available whether or not you'd installed plpgsql). There are
some places in the information_schema that desperately need it ---
right now, the value of FUNC_MAX_ARGS is effectively hard-wired into
some of the information_schema views, which means they are broken if
one changes that #define. We could fix this if we had a function like
the above and exported FUNC_MAX_ARGS as a read-only GUC variable.

First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
variable -- func_max_args. Comments?

While I was in guc.c, I also added short_desc to the definition of the
pg_settings view. I wasn't sure if I ought to add the long_desc too, and
if so, should it be it's own column in the view, or be concatenated with
short_desc -- any thoughts on that?

Current output looks like this:

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'func_max_args';
-[ RECORD 1 ]-----------------------------------------------------------
name | func_max_args
setting | 32
short_desc | Shows the compiled-in maximum number of function arguments.
context | internal
vartype | integer
source | default
min_val | 32
max_val | 32

This will require a catalog version bump when I apply it (not done in
the attached patch).

Joe

Joe Conway <mail@joeconway.com> writes:

First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
variable -- func_max_args. Comments?

One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.

I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN
* BLCKSZ
* integer-vs-float datetime flag
(Not sure about suitable GUC names for these --- func_max_args isn't out
of line as a GUC name, but surely BLCKSZ is.) NAMEDATALEN is needed for
many of the same reasons as FUNC_MAX_ARGS. BLCKSZ is probably useful
for pg_autovacuum. The datetime representation flag will be important
when people start using binary data transmission seriously --- without
it you can't tell what you'll get for a timestamp value. Essentially,
these are things we currently tell people to use pg_controldata to find
out, but that's quite an inconvenient solution.

While I was in guc.c, I also added short_desc to the definition of the
pg_settings view. I wasn't sure if I ought to add the long_desc too, and
if so, should it be it's own column in the view, or be concatenated with
short_desc -- any thoughts on that?

If it's there it should be separate. I think also there was some
feeling it should be called "extra_desc" not "long_desc".

+ 		/* Can't be set in postgresql.conf */
+ 		{"func_max_args", PGC_INTERNAL, UNGROUPED,
+ 			gettext_noop("Shows the compiled-in maximum number of function "
+ 						 "arguments."),
+ 			NULL
+ 		},
+ 		&func_max_args,
+ 		FUNC_MAX_ARGS, FUNC_MAX_ARGS, FUNC_MAX_ARGS, NULL, NULL
+ 	},

Please set the GUC_NOT_IN_SAMPLE and GUC_DISALLOW_IN_FILE flag bits on
each of these variables, too. I know we are not using these flags for
anything yet, but we should try to get them right...

regards, tom lane

Tom Lane writes:

One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.

You can determine these values by looking into the system catalogs.

I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN

And this as well.

* BLCKSZ

Why would anyone be interested in that?

* integer-vs-float datetime flag

Here we should really decide on one representation in the near term.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.

You can determine these values by looking into the system catalogs.

You can, but that does not mean that you should. I saw how you'd made
the information_schema code induce the value of NAMEDATALEN from type
NAME's typlen, and frankly I think it's remarkably ugly and fragile.
I do *not* want to recommend that client code do similar things to
induce these values. If we do that then we'll be wiring extremely
low-level assumptions into client code forevermore. Which of these
do you want to support into the indefinite future?

current_setting("func_max_args")

(SELECT typlen/4 from pg_type where typname = 'oidvector' and
typnamespace = (select oid from pg_namespace
where nspname = 'pg_catalog'))

I realize you think that using GUC variables for this purpose is a bit
of a bastardization of the GUC concept, and I can't really argue that
it isn't. But the fact is that GUC has succeeded beyond your wildest
dreams, and you should not be surprised that people now want to
piggyback on all that nice mechanism for other purposes. If we were to
invent some other concept for "access to read-only config variables",
then we'd just have to duplicate some large fraction of the
infrastructure that already exists for GUC. Why bother?

* BLCKSZ

Why would anyone be interested in that?

There was just a discussion a few days ago about the page size for large
objects, for which the correct answer was "BLCKSZ/4" IIRC. Whether
people actually *should* care about the page size of large objects I
dunno, but the fact is some of them *do* care.

* integer-vs-float datetime flag

Here we should really decide on one representation in the near term.

[shrug] If push comes to shove on a single representation, we will rip
out all that int8 stuff and go back to float8. This isn't negotiable;
we can't have a system that doesn't have working datetime functionality
on a machine without int8. I don't see that happening, though, so I
think we are going to be stuck with a compile-time choice for a long
time to come.

regards, tom lane

Peter Eisentraut wrote:

Tom Lane writes:

One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.

You can determine these values by looking into the system catalogs.

How, count? Seems we should give an easy API.

I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN

And this as well.

Again, why not make it easy.

* BLCKSZ

Why would anyone be interested in that?

Performance/admin tools might need this --- you need it to get the disk
size based on the number of pages recorded in pg_class.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.

I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN
* BLCKSZ
* integer-vs-float datetime flag

OK, the attached includes the above -- result looks like:

regression=# select * from pg_settings where category like 'Compile%';
-[ RECORD 1 ]----------------------------------------------
name | block_size
setting | 8192
category | Compiled-in Options
short_desc | Shows size of a disk block
extra_desc |
context | internal
vartype | integer
source | default
min_val | 8192
max_val | 8192
-[ RECORD 2 ]----------------------------------------------
name | func_max_args
setting | 32
category | Compiled-in Options
short_desc | Shows the maximum number of function arguments
extra_desc |
context | internal
vartype | integer
source | default
min_val | 32
max_val | 32
-[ RECORD 3 ]----------------------------------------------
name | index_max_keys
setting | 32
category | Compiled-in Options
short_desc | Shows the maximum number of index keys
extra_desc |
context | internal
vartype | integer
source | default
min_val | 32
max_val | 32
-[ RECORD 4 ]----------------------------------------------
name | integer_datetimes
setting | on
category | Compiled-in Options
short_desc | Datetimes are integer based
extra_desc |
context | internal
vartype | bool
source | default
min_val |
max_val |
-[ RECORD 5 ]----------------------------------------------
name | name_data_len
setting | 63
category | Compiled-in Options
short_desc | Shows the maximum identifier length
extra_desc |
context | internal
vartype | integer
source | default
min_val | 63
max_val | 63

If it's there it should be separate. I think also there was some
feeling it should be called "extra_desc" not "long_desc".

Done. Also added "category" which displays config_group_names[conf->group]

Please set the GUC_NOT_IN_SAMPLE and GUC_DISALLOW_IN_FILE flag bits on
each of these variables, too. I know we are not using these flags for
anything yet, but we should try to get them right...

Done.

I'll update the docs once I'm sure we're done iterating on these changes.

Any further comments?

Joe

Joe Conway <mail@joeconway.com> writes:

name | name_data_len
setting | 63
short_desc | Shows the maximum identifier length

Defining the value as NAMEDATALEN-1 is reasonable (I was thinking of
suggesting that myself), but it seems like a recipe for confusion to
use name_data_len to refer to NAMEDATALEN-1. Perhaps the GUC variable
name should be max_name_len or some such.

Also, should func_max_args and index_max_keys become max_func_args and
max_index_keys?

I'm not all that concerned about the names personally, but I want to
forestall any temptation for Bruce to start renaming these values later,
as he's felt free to do in the past ;-). My expectation is that the
names of these GUC variables will get embedded into client-side code
fairly quickly, and so it will not do to fool around with the names
later. We must decide what the naming convention is and then stick to
it.

regards, tom lane

Tom Lane wrote:

Perhaps the GUC variable name should be max_name_len or some such.

Also, should func_max_args and index_max_keys become max_func_args and
max_index_keys?

That sounds good to me:

-[ RECORD 3 ]----------------------------------------------
name | max_func_args
setting | 32
-[ RECORD 4 ]----------------------------------------------
name | max_index_keys
setting | 32
-[ RECORD 5 ]----------------------------------------------
name | max_name_len
setting | 63

I'll finish up the docs and commit this tomorrow, barring strong
complaints. It will require an initdb -- should I hold off for other
pending changes also requiring initdb?

Joe