Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I'm trying to avoid doing it in C as it seems like it would be a pita.
I think it would be simpler in C than this mess in SQL is ;-). You
would not of course implement it in any way that would look like the
SQL query ... but there are existing
> The right way to do this at the C level would be to use the same
> infrastructure as nextval() does to accept arguments like 'foo' and
> '"Foo"."Bar"'. There's no reason to restrict the two-argument form
> to the current search_path.
Is it possible to do that in SQL? eg. is there anything you
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> OK, attached is a file with the original function, and an overloaded one
> that just takes table and column. It searches your current search_path
> to find the first matching table.
The right way to do this at the C level would be to use the
I'd be inclined to make it only take 2 args, table, col where table can be
namespace qualified. This allows people who arn't namespace aware to just do
SELECT pg_get_serial_sequence('mytable','mycol') and have it return the
correct item following searchpath.. I would think this would then bec
On June 11, 2004 05:51 am, Christopher Kings-Lynne wrote:
> >>> 3. Or even create a pg_get_sequence() function:
> >>> SELECT SETVAL(pg_get_sequence(schema.table, col), 17);
> >>
> >> Actually, this is the best solution :)
>
> OK, attached is a pg_get_serial_sequence(schema, table, column) function
3. Or even create a pg_get_sequence() function:
SELECT SETVAL(pg_get_sequence(schema.table, col), 17);
Actually, this is the best solution :)
OK, attached is a pg_get_serial_sequence(schema, table, column) function
. I have tested it with crazy names and it seems to be good. It works
like this
On Jun 11, 2004, at 1:02 PM, Christopher Kings-Lynne wrote:
3. Or even create a pg_get_sequence() function:
SELECT SETVAL(pg_get_sequence(schema.table, col), 17);
Actually, this is the best solution :)
John Hansen and I worked this up. It works, though it's not
schema-aware, afaict.
create or rep
3. Or even create a pg_get_sequence() function:
SELECT SETVAL(pg_get_sequence(schema.table, col), 17);
Actually, this is the best solution :)
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subs
Yeah, I know ... we ought to find some way around that, but I dunno
what yet ...
My idea, which I tried hacking, but gave up was to do the following:
1. Extend this command:
ALTER SEQUENCE seqname RESTART WITH 17;
to allow:
ALTER SEQUENCE ON table(col) RESTART WITH 17...
or
ALTER SEQUENCE ON table.
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Then if the name given to the id sequence is now different, these dumps
> will not restore. (In this case it will be the same, I'm just
> illustrating the general problem of hard-coding those sequence names in
> the dump - I've never liked i
(moved to -hackers)
If you use sufficiently long table/field names then different tables
could truncate to the same generated names, and in that case there's
some risk of concurrently choosing the same "unique" name. But I don't
recall anyone having complained of that since we started using this
t
11 matches
Mail list logo